Skip to content

Instantly share code, notes, and snippets.

@TinyPoro

TinyPoro/Reasons for using design patterns.md

Forked from huynguyenptit/Reasons for using design patterns.md
Created March 20, 2018 17:03
Show Gist options
  • Save TinyPoro/a9dec845b1d96a337388bf8bb31eed67 to your computer and use it in GitHub Desktop.
Save TinyPoro/a9dec845b1d96a337388bf8bb31eed67 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Reasons for using design patterns.md

Source

Reasons for using design patterns

Introduction

Following on from a previous article entitled Why design is Critical to Software Development, I would like to tackle a slightly more advanced aspect of software design called Design Patterns. As with my previous article, the idea came about during a discussion concerning the merits of software design with a work colleague. The protagonist of the discussion was of the opinion that Design Patterns are too time consuming to be of use within the field of commercial software development. My intention here is to demonstrate why I believe that to be wrong.

I will not go into any details about the mechanics or implementation of any particular Design Patterns. There are many excellent sources for these available elsewhere.

What is a Design Pattern?

So getting started then, what exactly is a Design Pattern? Here are a couple of definitions for the term:

Extracted from Wikipedia:

"A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise."

Extracted from Data & Object Factory:

"Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges. "

So a Design Pattern is a general purpose abstraction of a problem, which can be applied to a specific solution. As software developers tend to solve many similar types of problems, it makes sense that any software solution would incorporate similar elements from other solutions. Why reinvent the wheel?

Well documented and understood

As Design Patterns are well documented and understood by software architects, designers and developers, then their application within a specific solution will likewise be well understood.

Design Patterns give a software developer an array of tried and tested solutions to common problems, thus reducing the technical risk to the project by not having to employ a new and untested design.

Design Patterns may not initially lead to a reduction in development timescales, as there is a learning curve if the team are unfamiliar with them. However, looking further down the development pipeline, once familiarity with them increases, development timescales should gradually reduce.

Close parallels with civil engineering

To give an analogy of a Design Pattern from the field of civil engineering (which as I stated in my article Why design is Critical to Software Development) has close similarities to software engineering), would be to think of a solution for crossing a river. This is a recurring problem for civil engineers, to which there are a couple of well documented and understood solutions. The civil engineers may build a bridge or a tunnel.

Why would a civil engineer try to solve this problem from scratch when there are real world solutions that can be referred to? There are close parallels between the civil engineer solving the river problem, and the software engineer solving a software problem:

  • The solutions (bridge or tunnel) are both well understood and documented
  • The solutions (bridge or tunnel) solve recurring civil engineering problems
  • The solutions (bridge or tunnel) are not deterministic or prescriptive, but are abstract and can be tailored to the specific problem to hand (the bridge or tunnel building materials for example can be selected for their alignment to the specific problem)

The argument against Design Patterns that they are not suitable for commercial use due to their taking too long to implement does not hold up. Design Patterns save time (when viewed over the lifetime of the application) by giving the developer a selection of tried and tested off-the-shelf solutions which they can tailor to their own specific needs.

The only issue I have come across with Design Patterns is that they take time to learn. Some of them can be difficult to grasp and comprehend. This is a reasonable criticism, as it therefore requires a more skilled developer to use them. This then may increase the project costs initially. However, when viewed over the lifetime of an application I would fully expect those initial development costs to be recouped due to the lower ongoing maintenance costs due to the higher comprehension and easier extensibility (making the application easier to extend in the future to meet new and emergent opportunities).

Design Patterns reduce complexity, and therefore the solution becomes easier to comprehend.

Design Patterns are tried and tested solutions, the developer does not need to start from scratch, and can hit the ground running with a solution that has been proven to work (as long as the Design Pattern being used solves a similar problem). It would be wrong to expect a bridge to solve the problem of crossing an ocean, where a bridge would simply be unsuitable.

Benefits of using Design Paterns

Design Patterns therefore provide the following benefits.

  • They give the developer a selection of tried and tested solutions to work with
  • They are language neutral and so can be applied to any language that supports object-orientation
  • They aid communication by the very fact that they are well documented and can be researched if that is not the case.
  • They have a proven track record as they are already widely used and thus reduce the technical risk to the project
  • They are highly flexible and can be used in practically any type of application or domain

Conclusion

Design Patterns, despite their initial learning curve, are a very worthwhile investment. They will enable you to implement tried and tested solutions to problems, thus saving time and effort during the implementation stage of the software development lifecycle. By using well understood and documented solutions, the final product will have a much higher degree of comprehension. If the solution is easier to comprehend, then by extension, it will also be easier to maintain.

Practice

Keyword: how to separate code to package php, step by step php design pattern singleton(change singleton to other for more result)

Raw
vi.md

Source

Lí do tại sao nên sử dung Design Patterns

Giới thiệu

Tiếp nối những bài viết trước với tựa đề [Tại sao thiết kế quan trọng đối với phát triển phần mềm][1], Tôi muốn giải quyết một khía cạnh nâng cao hơn một chút về thiết kế phần mềm được gọi là Patterns Design. Giống như bài viết trước của tôi, ý tưởng này được đưa ra trong một cuộc thảo luận liên quan đến sự thành công của thiết kế phần mềm với một đồng nghiệp làm việc. ~~Nhân vật chính~(protagonist)chủ đề chính của cuộc thảo luận là ý kiến ​​cho rằng "Design Pattern" quá tốn thời gian để sử dụng trong lĩnh vực phát triển phần mềm thương mại. Mục đích của tôi ở đây là để chứng minh tại sao tôi tin rằng đó là sai.

Tôi sẽ không đi quá chi tiết về cách thức hoạt động và việc thực hiện của bất kì một Design Patterns cụ thể. Có rất nhiều các mã nguồn tuyệt vời về nó có sẵn ở đâu đó.

Design Patterns là gì?

Vậy chúng ta bắt đầu ngay sau đây, Design Pattern thực sự là gì? Dưới đây là một cặp định nghĩa cho khái niệm này:

Theo [Wikipedia][2]:

Một Design Pattern là khoa học kiến trúc máy tính và được định nghĩa chính thức là 1 phương pháp để thiết kế vấn đề theo 1 cách chuyên môn

Theo [Data & Object Factory][3]:

Design patterns là cách giải quyết định kỳ cho các vấn đề thiết kế phần mềm mà bạn tìm hàng ngày trong quá trình phát triển ứng dụng thực tế. Các mẫu đề cập về việc thiết kế và tương tác giữa các đối tượng, cũng như cung cấp nền tảng giao tiếp liên quan đến việc giải quyết lại 1 cách dễ dàng các thách thức lập trình thường gặp. Do vậy Design Patter` là mục đích chung trừu tượng của 1 vấn đề, nó có thể được áp dụng vào các giải pháp cụ thể. Vì phát triển phần mềm có xu hướng giải quyết nhiều vấn đề tương tự nhau, nên có cảm giác rằng bất cứ giải pháp phần mèm nào cũng sẽ kết hợp với các phần tương tự trong các giải pháp khác. Vậy tại sao chúng ta phải đi theo cái lối mòn đó?

Vì vậy, `Design Pattern 'là một khái niệm chung của một vấn đề, có thể được áp dụng cho một giải pháp cụ thể. Khi các nhà phát triển phần mềm có xu hướng giải quyết nhiều loại vấn đề tương tự, điều đó có nghĩa là bất kỳ giải pháp phần mềm nào sẽ kết hợp các yếu tố tương tự từ các giải pháp khác. Tại sao phải phát minh lại bánh xe(reinvent the wheel)đi theo lỗi mòn cũ?

Tài liệu tốt và dễ hiểu

Vì Design Patterns được các nhà kiến ​​trúc sư, nhà thiết kế và phát triển phần mềm ghi nhận và hiểu rõ, thì ứng dụng của họ trong một giải pháp cụ thể cũng sẽ được hiểu rõ.

`Design Patterns cung cấp cho một nhà phát triển phần mềm một loạt các giải pháp được thử và thử nghiệm cho các vấn đề chung, do đó giảm nguy cơ kỹ thuật cho dự án bằng cách không phải sử dụng một thiết kế mới và chưa được kiểm tra.

Design Pattern có thể không dẫn đến giảm thời gian phát triển vì có một đường cong học tập nếu đội không quen với chúng. Tuy nhiên, nhìn sâu hơn xuống đường ống phát triển, một khi quen thuộc với chúng tăng lên, thời gian phát triển nên giảm dần.

Đóng các đường song song với kỹ thuật dân dụng

Để cung cấp cho một sự tương tự của một Design Patter từ lĩnh vực kỹ thuật dân dụng (mà như tôi đã nêu trong bài báo của tôi [Tại sao thiết kế là quan trọng để phát triển phần mềm] [1]) có điểm tương đồng gần với kỹ thuật phần mềm), có thể nghĩ đến một giải pháp để băng qua sông. Đây là một vấn đề thường xuyên đối với các kỹ sư dân dụng, trong đó có một số giải pháp được ghi nhận và hiểu rõ. Các kỹ sư dân dụng có thể xây dựng một cây cầu hoặc một đường hầm.

Tại sao một kỹ sư dân dụng cố gắng giải quyết vấn đề này từ đầu khi có những giải pháp thế giới thực có thể được đề cập đến(referred to)xem xét tới? Có sự tương đồng gần gũi giữa kỹ sư xây dựng giải quyết vấn đề về sông và kỹ sư phần mềm giải quyết vấn đề phần mềm:

  • Các giải pháp (cầu hoặc đường hầm) đều được hiểu và ghi lại
  • Các giải pháp (cầu hoặc đường hầm) giải quyết các vấn đề kỹ thuật xây dựng định kỳ
  • Các giải pháp (cầu hoặc đường hầm) không phải là xác định hoặc quy định, nhưng là trừu tượng và có thể được điều chỉnh cho các vấn đề cụ thể để bàn tay (cầu hoặc các vật liệu xây dựng đường hầm ví dụ có thể được lựa chọn cho sự liên kết của họ với các vấn đề cụ thể)

Lập luận chống lại Patterns Designs rằng chúng không phù hợp với mục đích thương mại do quá trình thực hiện lâu dài của chúng không thể giữ được. Design Patterns tiết kiệm được thời gian (khi xem qua suốt đời của ứng dụng) bằng cách cho nhà phát triển lựa chọn các giải pháp sẵn có và thử nghiệm sẵn có mà họ có thể tùy chỉnh theo nhu cầu cụ thể của riêng họ.

Vấn đề duy nhất tôi đã gặp 'Patterns Patterns' là họ dành thời gian để học. Một số người trong số họ có thể khó hiểu và hiểu. Đây là một lời chỉ trích hợp lý, vì nó đòi hỏi một nhà phát triển có tay nghề cao hơn sử dụng chúng. Điều này sau đó có thể làm tăng chi phí dự án ban đầu. Tuy nhiên, khi xem xét trong suốt thời gian sử dụng một ứng dụng, tôi sẽ hoàn toàn mong đợi những chi phí phát triển ban đầu này sẽ được bù đắp lại do chi phí bảo trì thấp hơn do sự hiểu biết cao hơn và khả năng mở rộng dễ dàng hơn (làm cho ứng dụng dễ dàng mở rộng trong tương lai để đáp ứng những cơ hội đang nổi lên).

Design Patterns làm giảm sự phức tạp, và do đó giải pháp trở nên dễ hiểu hơn.

Design Patterns là các giải pháp đã được thử nghiệm và thử nghiệm, nhà phát triển không cần phải bắt đầu từ đầu, và có thể chạy trên mặt đất với một giải pháp đã được chứng minh là có hiệu quả (miễn là Design Pattern được sử dụng giải quyết một vấn đề tương tự ). Sẽ là sai khi mong đợi một cây cầu để giải quyết vấn đề băng qua đại dương, nơi(where)khi một cây cầu chỉ đơn giản là không phù hợp.

Lợi ích của việc sử dụng Design Patterns

Design Patterns do đó cung cấp những lợi ích sau đây.

  • Họ cung cấp cho nhà phát triển một lựa chọn các giải pháp được thử và thử nghiệm để làm việc với
  • Họ là ngôn ngữ trung lập và do đó có thể được áp dụng cho bất kỳ ngôn ngữ hỗ trợ hướng đối tượng
  • Họ hỗ trợ truyền thông bởi thực tế là họ có tài liệu tốt và có thể được nghiên cứu nếu đó không phải là trường hợp.
  • Họ có một hồ sơ đã được chứng minh là(as)khi đã được sử dụng rộng rãi và do đó làm giảm nguy cơ kỹ thuật cho dự án
  • Họ rất linh hoạt và có thể được sử dụng trong thực tế bất kỳ loại ứng dụng hoặc tên miền

Phần kết luận

`Design Patterns ', mặc dù đường cong học tập ban đầu, là một sự đầu tư rất đáng giá. Họ sẽ cho phép bạn thực hiện các giải pháp được thử và thử nghiệm cho các vấn đề, do đó tiết kiệm thời gian và nỗ lực trong giai đoạn triển khai của vòng đời phát triển phần mềm. Bằng cách sử dụng các giải pháp được hiểu rõ và có tài liệu, sản phẩm cuối cùng sẽ có một mức độ hiểu biết cao hơn nhiều. Nếu giải pháp được dễ dàng hơn để hiểu, sau đó bằng cách mở rộng, nó cũng sẽ được dễ dàng hơn để duy trì.

[1]: http://www.codeproject.com/Tips/806867/Lý do-Design-is-Critical-to-Software-Development [2]: http://en.wikipedia.org/wiki/Design_pattern [3]: http://www.dofactory.com/Patterns/Patterns.aspx

Thực hành

** Keyword: ** làm thế nào tách code ra khỏi gói php, từng bước mẫu thiết kế php singleton (thay đổi singleton để khác cho kết quả khác)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment