Bất cứ ai cũng có thể đọc cuốn sách GoF để tìm hiểu các mẫu thiết kế là gì và cách sử dụng chúng, nhưng quy trình để tìm ra khi một mẫu thiết kế giải quyết vấn đề là gì? Liệu kiến thức về mẫu có thúc đẩy thiết kế hay không, liệu có cách nào để tìm ra cách một mẫu có thể được sử dụng để thay đổi một thiết kế?Làm thế nào để bạn biết khi nào nên sử dụng các mẫu thiết kế?
Nói cách khác, có mẫu cho Mẫu không?
Các mẫu thiết kế có nghĩa vụ cung cấp cấu trúc trong đó có thể giải quyết được sự cố. Khi giải quyết một vấn đề thực sự, bạn phải xem xét nhiều các biến thể nhỏ của giải pháp cho vấn đề đó để xem liệu có phù hợp với một mẫu thiết kế hay không. Đặc biệt, bạn có thể sẽ cần phải khái quát hóa vấn đề của bạn, hoặc giải pháp của nó, để làm cho một mẫu thiết kế phù hợp.
Câu trả lời là, đó là một nghệ thuật. Biết các mẫu thiết kế chắc chắn là một bước quan trọng. Một cách để làm quen với điều này là nghiên cứu các ứng dụng của các mẫu thiết kế, không chỉ các mẫu. Nhìn thấy nhiều ứng dụng khác nhau của một mẫu có thể giúp bạn theo thời gian để có được tốt hơn khi lập bản đồ một tác vụ lên một mẫu.
Tôi rất khuyên bạn nên đọc Head First Design Patterns từ O'Reilly. Điều này giải thích cách các mẫu này có thể được sử dụng trong thế giới thực.
Tôi cũng thêm rằng không thử thiết kế quá nhiều với các mẫu trong đầu. Hơn nữa, hãy tìm "mã mùi" mà một mô hình có thể giúp giải quyết.
Có, tôi có cuốn sách đó. Nó thật sự tốt. Tôi không quan tâm đến các ví dụ (vịt và pizza và điều gì), nhưng nó mang lại một nền tảng vững chắc về các mẫu thiết kế. –
Nhưng các ví dụ trong cuốn sách này (với pizza, nhà máy sô cô la và vv) thực sự giúp bạn nắm bắt được khái niệm và ý tưởng về từng mẫu. –
Cảm giác giống như kiểu thiết kế được tiêm vào não. Thực sự là một cuốn sách tuyệt vời. – Jnana
Trải nghiệm. Tìm hiểu các mẫu và ví dụ thực tế về cách sử dụng của chúng. Mỗi khi bạn có quyết định thiết kế, hãy suy nghĩ xem một mẫu mà bạn biết sẽ áp dụng cho nó hay không. Theo thời gian, bạn sẽ trở nên tốt hơn và bạn khám phá những cách mới để áp dụng các mẫu cho một loạt các vấn đề.
Và một trong những nơi tốt nhất để tìm hiểu cách nhận ra các mẫu thiết kế là trong một Dojo mã hóa, nơi những người tham gia tham gia vào "thực hành có chủ ý" với các vấn đề về đồ chơi (Xem http://en.wikipedia.org/wiki/Kata_(programming)). Các nhóm người dùng cục bộ đôi khi lưu trữ dojos. Nhưng, ngay cả khi không thể tìm thấy một dojo để tham gia, có rất nhiều giá trị trong việc chạy qua katas một mình. –
Một cuốn sách tuyệt vời, tôi tìm thấy là:
Refactoring để Patterns
Bằng cách hiển thị khi nào, ở đâu và làm thế nào bạn có thể thay đổi mã hiện có để mô hình, nó đã cho tôi một sự hiểu biết tốt hơn về các khái niệm, và một khả năng xác định nơi chúng có thể được sử dụng.
Bạn đã học cách sử dụng câu lệnh if như thế nào?
Tôi so sánh nó với điều đó bởi vì nó là một cấu trúc lớn hơn mà bạn cần phải biết trước và ngoài trước khi bạn có thể sử dụng nó một cách hiệu quả. Một câu lệnh if giải quyết một lớp các vấn đề cần phân nhánh. Một mô hình cầu giải quyết một lớp các vấn đề. Tôi thực sự không xem chúng khác nhau.
Nếu bạn biết các mẫu, sau đó chúng trở thành công cụ trong hộp công cụ của bạn. Khi bạn nhìn vào một công việc, bạn chọn từ các công cụ của bạn. Tại thời điểm đó, bạn nên có một ý tưởng khá tốt mà công cụ là phù hợp nhất cho một vấn đề nhất định. Đây là nơi công thức ngừng hoạt động và bạn thực sự làm công việc kỹ thuật.
Tôi đồng ý rằng chỉ cần học các mẫu là không đủ. Vấn đề với hầu hết các cuốn sách là chúng không cung cấp các ví dụ trong thế giới thực. Tôi đã nghe nói rằng các mẫu thiết kế đầu tiên, như một số đề xuất trước đó, là một trong những tốt nhất.
Một điều nữa là hầu hết các sách đều cố ý không phải ngôn ngữ cụ thể, có thể vừa là điều tốt hay xấu cho bạn. Tuy nhiên, điều quan trọng là phải hiểu một mô hình nói chung, cũng không kém phần quan trọng để biết cách triển khai thực hiện tốt như thế nào. Tôi đã đi qua một cuốn sách gọi là C# 3.0 Design Patterns mà chỉ dành khoảng mực bằng nhau cho cả hai khía cạnh không thể tách rời này.
Tôi đã có cùng một câu hỏi này khi lần đầu tiên tôi gặp phải các mẫu thiết kế. Tôi đánh giá cao các khái niệm, nhưng không biết khi nào hoặc làm thế nào để áp dụng chúng. Cách tiếp cận ban đầu của tôi là tìm kiếm khả năng ứng dụng trong giai đoạn thiết kế. Một khi bạn có một sơ đồ khối và trách nhiệm bán rõ ràng cho mỗi khối, nó không quá khó để có trách nhiệm và tham khảo chéo chúng với một cuốn sách tham khảo phong nha. Một số tốt đã được đề cập ở đây, nhưng một trong những GoF nên có trong danh sách của bạn. Bước tiếp theo là tìm kiếm các cải tiến trong thiết kế dựa trên những gì bạn thấy trong các mẫu.
Mẫu thiết kế? Bạn đang ngâm trong họ!
Không có gì đặc biệt về các mẫu thiết kế, chúng chỉ là các mẫu thiết kế. Tất cả phát triển đều sử dụng các mẫu thiết kế. Có một tập hợp các mẫu thiết kế nhất định trong lập trình hướng đối tượng được coi là thường mong muốn và đã trở thành các Mẫu thiết kế chuẩn tắc. Nhưng cũng có nhiều mẫu thiết kế không quan tâm hoặc không quan tâm (chẳng hạn như design anti-patterns) cũng như các mẫu chưa được khám phá và/hoặc không có giấy tờ.
Bạn không thể tránh sử dụng các mẫu khi lập trình. Nhưng bạn có thể trở nên ý thức hơn về các mẫu bạn đang sử dụng và khi nào các mẫu nhất định hữu ích và khi chúng không có. Nghiên cứu các Mẫu thiết kế kinh điển từ số GoF book sẽ giúp, như sẽ tìm hiểu về code smells and refactoring. Không có câu trả lời đúng cho khi thiết kế hoặc mẫu thiết kế cụ thể nên được sử dụng, bạn cần phải xây dựng kinh nghiệm trong việc sử dụng và triển khai chúng để biết khi nào và ở đâu để sử dụng mẫu nào.
Bật câu hỏi: mẫu mtch bạn nên tạo là "mẫu phù hợp với vấn đề của tôi". Hãy xem xét một mô hình thực sự đơn giản, tìm kiếm một phần tử trong một mảng. trong C, nó giống như là
TYPE_t ary[SIZE] = // ... gets initialized somehow
size_t ix ; // Your index variable
for(ix=0; ix < SIZE; ix++){
if (ary[ix] == item) {
return ix ;
}
}
Bạn không nhìn vào mã và nghĩ "Tôi có thể sử dụng cái đó ở đâu", bạn xem xét vấn đề và nói "tôi biết cách tìm phần tử trong mảng ? "
Với nhiều kiểu mở rộng hơn thực sự hoạt động theo cùng một cách. Bạn cần có nhiều bản sao của một cấu trúc dữ liệu không thay đổi thường xuyên --- điều đó khiến bạn nghĩ "Flyweight". Bạn muốn một cái gì đó mà sống trên cả hai mặt của một ranh giới mạng, bạn nghĩ rằng Proxy.
Khi bạn nghiên cứu các mẫu, đặc biệt là GoF, hãy tự hỏi mình "những tình huống nào cho mẫu này? Tôi có thấy mô hình này trước đây không? Tôi có thể sử dụng mẫu này trong tác phẩm trước đây ở đâu? Tôi có thể tìm ví dụ này ở đâu cuộc sống của tôi?"
Có một khái niệm cơ bản về các mẫu cơ bản mà hầu hết mọi người không bị lúng túng. Đừng nghĩ chúng là cấu trúc dữ liệu hay thuật toán.
Thay vào đó, hãy nghĩ mã của bạn là những người gửi thư, như gửi ghi chú hoặc gửi thư cho nhau. Mỗi đối tượng là một 'người'.
Cách bạn sắp xếp 'người' và các mẫu họ sử dụng để gửi tin nhắn cho nhau là các mẫu.
Khái niệm về mẫu thiết kế đã được lấy từ kỹ thuật kết cấu, cũng như với nhiều thực tiễn trong kỹ nghệ phần mềm. Nếu bạn xem xét việc xây dựng một cấu trúc, có những quyết định cần phải được thực hiện về cách xây dựng cấu trúc đó để đạt được các mục tiêu đã đề ra. Khi đưa ra các quyết định đó, bạn sẽ có một bộ các yêu cầu để làm việc. Nó có thể là một cái gì đó đơn giản như Bridge phải có khả năng hỗ trợ X tấn cùng một lúc, hoặc có độ bền kéo đặc biệt để cho phép đủ chuyển động trong gió vv. Một kiến trúc sư sẽ sử dụng kiến thức trước về các bản dựng khác để thực hiện những lựa chọn thiết kế đó. Anh/Cô ấy sẽ không thể cố gắng giải quyết vấn đề từ đầu.
Mẫu thiết kế và kỹ thuật phần mềm hoàn toàn giống nhau. Chúng đơn giản là giải pháp phổ biến cho các vấn đề chung. Nếu bạn biết các mẫu thiết kế, sau đó khi bạn đang làm việc thông qua một thiết kế, và một phần cụ thể của một hệ thống yêu cầu một cái gì đó phù hợp với một mẫu thiết kế bạn có, sau đó sử dụng nó. Đừng cố gắng để phù hợp với một hệ thống tròn một mẫu thiết kế, phù hợp với các mẫu thiết kế trong hệ thống của bạn (nơi chúng phù hợp). Chỉ cần cố gắng nghĩ về chúng như là một tập hợp các giải pháp để giảm số lượng công việc thiết kế mà bạn cần làm, và thận trọng hơn việc xây dựng các giải pháp của bạn để nhồi nhét nhiều mẫu thiết kế nhất có thể. Điều này sẽ chỉ phục vụ để làm cho giải pháp của bạn unmaintainable và có lẽ khá buggy.
Rian van der Merwe đã viết một số excellent article về việc này cho Tạp chí Smashing vào tháng 6 năm 2012. Dưới đây là một số dấu đầu dòng nổi bật.
mẫu thiết kế này rất hữu ích vì hai lý do:
van der Merwe khuyến cáo rằng chúng ta xem xét mô hình phá vỡ khi:
Đó là một kiểu thiết kế khác, nhưng câu trả lời của bạn vẫn tuyệt vời. :) –
Một mẫu thiết kế là một mô tả chung chung về cách giải quyết một vấn đề thường gặp. Có 2 điều chúng ta nên chú ý:
Đầu tiên, nó là Mô tả chung; nó không phải là giải pháp cụ thể, và nó không phải là một công thức hoàn chỉnh, nó chỉ là một mô tả về cách giải pháp sẽ như thế nào để tiếp cận một vấn đề chung.
Thứ hai, vấn đề là câu hỏi là một vấn đề thường gặp :, có nghĩa là vấn đề này đã được gặp nhiều lần trước đây, và theo thời gian mọi người đã phát triển một mô tả cho cách một giải pháp lý tưởng có thể được áp dụng cho này thường được lặp đi lặp lại vấn đề. Vì vậy, nếu bạn gặp phải một vấn đề mới không phổ biến, hãy cố gắng không sử dụng các mẫu thiết kế để giải quyết nó, hoặc ít nhất không tạo ra các mẫu thiết kế công cụ của bạn để giải quyết mọi vấn đề mà bạn gặp phải.
Làm cách nào để nghiên cứu các ứng dụng khác nhau khi chúng không được ghi nhận? Trong thế giới thực, chúng tôi áp dụng và tiếp tục. Làm thế nào để tìm nguồn đó, nơi chúng ta có thể nghiên cứu về ứng dụng thành công trước khi áp dụng ??? Nguồn gốc ở đâu ?? –
cho người đàn ông này một ly bia. – user1262904