Vì vậy, thật lạ khi đặt hai câu hỏi ngược lại, nhưng chúng không liên quan lắm và tôi không muốn kết hợp chúng, nhưng tôi không hứa là những câu hỏi spam, tôi hứa!

Dù sao, tôi là một sinh viên tốt nghiệp đại học gần đây, và giáo dục của tôi chỉ chạm vào các mẫu thiết kế ... chúng tôi đã thực hiện một vài cái đơn giản, chạm vào thực tế là có những cái phức tạp hơn, và được hướng dẫn chuyển sang sách GoF nếu chúng tôi muốn tìm hiểu thêm. Câu hỏi của tôi là, nó có đáng để học các mô hình trong cuốn sách GoF không? Đối với tôi, dường như luôn phản tác dụng để thử và làm cho một vấn đề phù hợp với một mô hình cổ điển, nhưng rõ ràng cuốn sách và các mô hình, nổi tiếng vì một lý do. Họ có xuất hiện đủ rằng tôi nên học chúng không?

Cảm ơn một lần nữa!

Như thường lệ

Nó phụ thuộc

Nó phụ thuộc vào số lượng OOP bạn đã thực hiện để xem bạn có nhận ra hoặc thậm chí có thể sử dụng các mẫu thiết kế không

Nó phụ thuộc vào mức độ kỷ luật của bạn như thế nào về việc bạn sẽ áp dụng các mô hình một khi đã học chính xác, và không trở nên điên rồ như người hoạt ngôn với cây búa

Mặt khác ... năm ngón tay!

Nếu bạn đã thực hiện một vài năm làm việc OOP nghiêm túc hoặc bạn có một người cố vấn đáng tin cậy để giữ bạn trên đường ray hoặc bạn chỉ thích đọc OOP-nerd, thì bằng mọi cách hãy đi mua sách và nghiên cứu nó.

Nó giúp biết các mẫu để bạn nhận ra khi nào nên sử dụng chúng và khi nào không sử dụng chúng.

Vâng, bạn nên tìm hiểu chúng.

Việc xem lại chúng sau khi bạn có được một số kinh nghiệm sẽ có ý nghĩa hơn , để bạn có thể so sánh chúng với những gì bạn biết. Đối với một số mẫu, hóa ra đây là thứ bạn tự khám phá, nhưng bạn sẽ học được một cái gì đó tổng quát hơn về cách sử dụng, sự đánh đổi, các biến thể, v.v. Những người khác có thể trực tiếp giải quyết các vấn đề bạn đã đối phó và chỉ cho bạn một giải pháp tao nhã mà bạn không biết.

Vĩ đại đa số các mẫu là rất hữu ích và phổ biến . Những người khác có thể không phổ biến như vậy, nhưng vẫn có một số cách sử dụng hẹp, nơi chúng phù hợp hoàn hảo.

Có thêm một lý do tại sao nó đáng đọc: Nó sẽ dạy bạn cách suy nghĩ . Chắc chắn, nó không phải là một viên đạn bạc, nhưng vẫn là một nguồn cảm hứng vô giá.

Cuối cùng nhưng không kém phần quan trọng, không bao giờ, trong mọi trường hợp, hãy thử và làm cho một vấn đề phù hợp với một mô hình hoặc công cụ . Đó là suy nghĩ rất xấu và nguy hiểm! Hiểu cách thức hoạt động của công cụ và sử dụng nó một cách khôn ngoan để giải quyết vấn đề, không bao giờ ngược lại.

Càng nhiều công cụ bạn biết tốt, càng tốt. Đôi khi một công cụ có thể truyền cảm hứng cho suy nghĩ của bạn (thay vì giải quyết vấn đề trực tiếp), một lần khác bạn sẽ kết hợp một vài trong số chúng để có giải pháp tuyệt vời.

Cuốn sách GOF là một nguồn tuyệt vời của nhiều công cụ hữu ích mà chúng ta sử dụng hàng ngày .

Lợi ích quan trọng nhất từ ​​việc biết một chút về Design Patters, là bạn biết các thuật ngữ này có nghĩa gì. Nói cách khác, bạn biết từ vựng thông dụng .

Đối với tôi, đây là thành tựu quan trọng nhất trong tất cả các biến động của Mẫu thiết kế, rằng một từ vựng thông thường đã phát sinh khi bạn chỉ cần sử dụng tên của các mẫu cụ thể và những người khác biết ngay bạn đang nói về điều gì mà không cần phải giải thích nó. . Những điều mà các mô hình mô tả được hầu hết các lập trình viên biết đến, nhưng cần có thời gian để giải thích ý nghĩa của bạn với người khác, vì vậy nó giúp giao tiếp dễ dàng hơn để biết tên các mẫu.

Ví dụ là Khách truy cập, Singleton và Trang trí.

Nói cách khác, tôi khuyên bạn nên làm quen ít nhất với tên và những gì họ làm.

CÓ nhưng với sự thận trọng!

Phần CÓ:

Đôi khi, chúng tôi gặp phải vấn đề trong thiết kế của chúng tôi. Đôi khi những vấn đề đó rất phổ biến, vì vậy một mẫu thiết kế cung cấp cho bạn các giải pháp được kiểm tra tốt cho những vấn đề đó. Những lợi ích chính của việc học các mẫu thiết kế là bạn có thể đưa ra giải pháp thiết kế nhanh hơn rất nhiều và nếu đồng nghiệp của bạn biết về biệt ngữ mẫu thiết kế , bạn cũng có thể giải thích một giải pháp nhanh hơn rất nhiều.

Phần thận trọng:

Các mẫu thiết kế không nên là chén thánh trong các giải pháp của bạn. Giải pháp đơn giản nhất (KISS) là mong muốn hơn và nhiều lần các mẫu thiết kế sẽ làm cho mọi thứ phức tạp hơn. Nếu bạn đang học các mẫu thiết kế, cũng tìm hiểu về các mẫu chống. Tôi biết một số người cũ chống lại các mẫu thiết kế và tôi đồng ý ở một mức độ nào đó với họ bởi vì khi bạn không có quá nhiều kinh nghiệm mã hóa nhưng tải lý thuyết mẫu thiết kế, bạn có thể sẽ làm cho bạn và bạn khó khăn hơn rất nhiều đội.

Cuối cùng, Đừng nghĩ rằng bạn phải phù hợp / thay đổi giải pháp của mình chỉ để tuân thủ một mẫu thiết kế. Ngược lại, bạn có thể uốn cong một mẫu thiết kế để nó có thể phù hợp với giải pháp của bạn. Không sao nếu bạn không sử dụng mọi thành phần của một công thức mẫu thiết kế miễn là bạn có giải pháp tốt hơn cho vấn đề cụ thể của mình. Hãy nghĩ về các mẫu thiết kế như một gợi ý và không phải là quy tắc cho giải pháp của bạn.

Tôi đã tìm thấy phương pháp suy nghĩ của Mục tiêu Net về việc vỗ về là có lợi nhất. Những người đọc sách GoF quá thường xuyên bắt đầu cho rằng các cấu trúc họ hiển thị, trong ký hiệu thiết kế và mã, là các mẫu và đây luôn là giao diện của chúng. Có một cách khác, được cho là tốt hơn để nhìn vào nó.

Các mẫu là các tập hợp các vấn đề tương tự có thể được giải quyết bằng các công thức trừu tượng nhất định, không phải là các bộ công thức có thể được sử dụng để giải quyết các vấn đề khác nhau. Điều này có nghĩa là mẫu đã có sẵn trước khi bạn bắt đầu thử thiết kế, đối tượng của nhà thiết kế là tìm nó chứ không phải áp đặt nó.

Hơn nữa, rất nhiều người nhìn vào các mẫu và nói, "Ồ, tôi chỉ giải quyết điều đó bằng cách .... Tôi không sử dụng các mẫu ngớ ngẩn." Vấn đề là "...." gần như chắc chắn mô tả việc triển khai AN của một giải pháp mẫu nhất định. Ví dụ, một loạt các con trỏ hàm có thể đóng vai trò là Chuỗi trách nhiệm mặc dù đây không phải là công thức truyền thống.

Với suy nghĩ này, trọng tâm trong nghiên cứu về các mẫu của bạn nên tập trung vào các vấn đề, chứ không phải các mẫu. Tìm hiểu các yếu tố thúc đẩy của các mẫu và cách chúng giải quyết các yếu tố đó. Làm điều này sẽ cho phép bạn nhìn thấy các mẫu trong vấn đề và sau đó chỉ cần chỉ ra chúng. Điều này, cùng với ngôn ngữ mà các mẫu cho chúng ta nói về thiết kế, cho phép bạn đưa ra một thiết kế phù hợp để trả lời những khó khăn khác nhau mà bạn hiện đang gặp phải.

CÓ, nói tóm lại, mô hình học tập không chỉ có giá trị ... bạn tự giới hạn mình bằng cách KHÔNG học chúng. Tôi không muốn phải mô tả tất cả các nguyên tắc thúc đẩy và hình dạng chung của giải pháp khi tôi nói, "Trông giống như một vị khách đến với tôi."

Đây là trang web của họ: http://www.netobjectives.com/PotypeRep repository / index.php? Title = Main_Page

Các mẫu thiết kế được mô tả bởi GoF là một phần mở rộng tự nhiên của mô hình OO. Nếu bạn không hiểu kỹ các mục tiêu của OOP (đóng gói, phân tách các mối quan tâm, nguyên tắc DRY, mô đun hóa, v.v.), thì việc thử áp dụng Mẫu thiết kế thành công sẽ không có ý nghĩa nhiều.

Tuy nhiên, nếu bạn bị ướt chân trong OOP trong thế giới thực và cố gắng trung thành với các giá trị OOP, bạn chắc chắn sẽ gặp phải các tình huống như mô tả của GoF và rất có thể bạn sẽ phát minh ra các giải pháp tương tự như của họ. Đã giải quyết được rất nhiều vấn đề tương tự, bạn có thể bắt đầu thấy các mô hình xuất hiện; tại thời điểm này, nó có ý nghĩa để đọc cuốn sách; lý tưởng nhất là bạn sẽ có cảm giác được công nhận và ngay lập tức bạn sẽ đánh giá cao sự thanh lịch và sạch sẽ của các mẫu được đề xuất. Rất có thể bạn cũng sẽ xem xét một số mô hình không có trí tuệ này (mà một khi bạn biết chúng, nhiều trong số chúng là). Bạn cũng sẽ có thể đánh giá tốt liệu một mô hình nhất định có được áp dụng trong một tình huống nhất định hay không.

Và đây là một cảnh báo khác: Chỉ vì bạn biết tất cả các mẫu này không có nghĩa là bạn phải áp dụng chúng ở mọi nơi. Một số trong số chúng khá thông minh và mọi người rất muốn sử dụng chúng ngay cả khi chúng không phù hợp khủng khiếp, mẫu Singleton là ví dụ nổi tiếng nhất (phần lớn các tranh cãi của Singleton xuất phát từ việc sử dụng không phù hợp, ví dụ như khi không có lợi ích gì ràng buộc chỉ có trong tài khoản).

Các mẫu thiết kế cố gắng giải quyết các vấn đề của desing.

• Chúng được tạo ra AFAIK chủ yếu cho các ngôn ngữ OOP.
• Một số vấn đề không tồn tại trong lập trình chức năng (Mẫu lệnh là cách tạo các hàm hạng nhất, Mẫu chiến lược xấp xỉ hàm bậc cao hơn ...). Các mẫu này dành cho các ngôn ngữ (chủ yếu là OOP) không có chức năng cần thiết.
• Chúng được sắp xếp theo thứ tự abc. Một số mẫu là thành phần của những người khác hoặc các ý tưởng được cấu thành từ những cái đã có trước đó.

Tôi đã học các mẫu sau đó, sau khi tôi biết một số lập trình chức năng, UML, desing cơ sở dữ liệu, cấu trúc dữ liệu và thuật toán. Tôi thực sự đã nghĩ đến danh sách thiết kế các mẫu này trên áo và gật đầu rằng tôi đã biết hầu hết chúng. Một số thực sự đẹp như mẫu đơn hoặc "giao tiếp" (khách truy cập, hòa giải viên) ...

Tôi đồng ý với các điểm được đưa ra trong một số câu trả lời khác về việc có thể nguy hiểm như thế nào khi áp dụng các mẫu thiết kế với ít kinh nghiệm.

Tuy nhiên, tôi đặc biệt khuyên bạn nên đọc ít nhất chương đầu tiên của cuốn sách GoF. Phần đầu tiên sẽ giới thiệu cho bạn các mẫu thiết kế, nhưng thực sự là nhiều hơn về các nguyên tắc của thiết kế OO, và điều này sẽ có ích để đọc và hiểu ngay cả với tương đối ít kinh nghiệm. (Một số ý tưởng chính mà tôi nhớ bao gồm "gói gọn các khái niệm khác nhau", "hệ thống phân cấp thừa kế nên rộng nhưng không sâu".) thông báo những mẫu đó cũng vô cùng quý giá.

Câu hỏi của tôi là, nó có đáng để học các mô hình trong cuốn sách GoF không?

Chắc chắn rồi! Bạn không chỉ học các mẫu thiết kế phần mềm, mà cả các kỹ thuật thiết kế nói chung. Học các giải pháp chung cho các vấn đề chung là một khởi đầu tuyệt vời. Đặc biệt là một khi bạn bắt đầu đào sâu vào các mô hình và sự đánh đổi của họ.

Họ có xuất hiện đủ rằng tôi nên học chúng không?

Cuốn sách Gang of Four ban đầu được phát triển bằng cách kiểm tra nhiều dự án phần mềm và xem các kỹ thuật mà một số nhà phát triển đã sử dụng để giải quyết vấn đề. Các tác giả nhận thấy một vài kỹ thuật thực sự tốt, cũng như một số được áp dụng trong các dự án rất rời rạc và làm việc để trừu tượng hóa chúng thậm chí còn được sử dụng nhiều hơn bất kể tên miền.

Nó luôn có vẻ phản trực giác để thử và làm cho một vấn đề phù hợp với một mô hình cổ điển

Đây là một vấn đề lớn. Bạn không làm cho một vấn đề phù hợp với giải pháp. Thay vào đó, sách mẫu thiết kế Gang of Four có phần "vấn đề" cho từng mẫu và các danh mục mẫu khác có các phần tương tự, mô tả khi nào bạn nên áp dụng từng mẫu. Nó cũng mô tả "hậu quả" của việc sử dụng mẫu - nếu bạn đang cố tránh hậu quả, thì sử dụng mẫu không phải là ý tưởng tốt nhất.