Các mẫu thiết kế nói chung là một lực cho tốt hay xấu? [đóng cửa]

Tôi đã nghe nói rằng các mẫu thiết kế là thứ tốt nhất kể từ khi bánh mì cắt lát. Tôi cũng nghe nói rằng các mẫu thiết kế có xu hướng làm trầm trọng thêm "Hội chứng hệ thống thứ hai", rằng chúng bị lạm dụng quá mức và chúng khiến người dùng nghĩ rằng chúng là những nhà thiết kế giỏi hơn thực tế.

Tôi có xu hướng rơi gần hơn đến trại cũ, nhưng gần đây tôi đã thấy các thiết kế trong đó gần như mọi tương tác đơn lẻ được thay thế bằng mối quan hệ người quan sát và mọi thứ đều là đơn lẻ.

Vì vậy, xem xét các lợi ích và vấn đề, các mẫu thiết kế nói chung là tốt hay xấu, và tại sao?

Các mẫu thiết kế là một ngôn ngữ , không phải lời khuyên để viết chương trình hoặc hợp đồng. Việc sử dụng chính của họ là một lời giải thích về hậu sinh như thế nào một thành phần hoặc một hệ thống đã (hoặc sẽ được) thực hiện. Thay vì đi vào quá nhiều chi tiết, bạn chỉ có thể nói một vài từ có thể mô tả việc thực hiện đủ tốt để người nghe hiểu cách thức hoạt động của nó và điều gì là quan trọng trong đó.

Alex: Hey, các tập tin cấu hình được tạo ra như thế nào?

Bob: Chúng được tạo ra bởi một nhà máy, nằm trong đó config.h.

Bây giờ Alex biết rằng việc tạo các tệp cấu hình liên quan đến các chuẩn bị không tầm thường, bởi vì nếu không thì việc tạo ra chúng sẽ không được đưa vào một nhà máy.

Tuy nhiên, nếu Bob là một kẻ giả mạo theo mô hình và chỉ sử dụng các mẫu ở đây và đó, Alex không thể nói bất cứ điều gì về việc tạo cấu hình, bởi vì Bob đã sử dụng nhà máy ở khắp mọi nơi. Điều này cũng sẽ dẫn đến sự phức tạp quá mức trong chương trình.

Vì vậy, hãy lập trình trước, sau đó phát hiện các mẫu trong mã của bạn chứ không phải ngược lại. Đó là cách chúng được sử dụng hiệu quả.

Mẫu thiết kế rất tuyệt . Khi được sử dụng đúng cách, chúng làm cho mã dễ bảo trì hơn, dễ đọc và dễ làm việc hơn. Một phần của việc trở thành một lập trình viên giỏi là biết khi nào nên dừng lại và thấy rằng bất kỳ tái cấu trúc nào nữa sẽ vượt trội hơn lợi ích. Chỉ sử dụng các mẫu thiết kế không làm cho ai đó trở thành một lập trình viên giỏi, nhưng biết khi nào và sử dụng chúng ở đâu. Giống như với bất cứ điều gì khác trong thế giới này, các mẫu thiết kế có thể bị cực đoan và bị lạm dụng. Tôi biết tôi vẫn đang tìm kiếm (và sẽ tồn tại trong một thời gian dài) cho sự cân bằng hoàn hảo trong mã của tôi, nơi mọi mẫu thiết kế đều có một mục đích và rơi vào vị trí hoàn hảo giống như một mảnh ghép hình.

Mẫu thiết kế là tuyệt vời, nếu sử dụng đúng.

Thật hữu ích khi nhớ rằng ý tưởng về các mẫu thiết kế bắt nguồn từ kiến ​​trúc. Kiến trúc có thể thay đổi dữ dội. Tuy nhiên, có nhiều ý tưởng cốt lõi có mặt trong bất kỳ tòa nhà nào. Theo cách này, hãy nghĩ về các mẫu như các khối xây dựng của thiết kế. Điều quan trọng cần lưu ý là không phải mọi tòa nhà đều bao gồm tất cả các mẫu kiến ​​trúc có thể.

Giả sử bạn đang thiết kế một ngôi nhà. Thay vì mở cửa trước ra đường, bạn muốn có một khu vực được che chở trước khi vào nhà, tức là một phòng chờ. Khu vực này sẽ phù hợp với một mô hình nhất định. Cụ thể, nó sẽ có hai lối vào, một số bức tường và có thể là một mái nhà. Lưu ý, mẫu không chỉ định cửa ra vào, cửa sổ hoặc có bao nhiêu bức tường. Trong hầu hết các triển khai, sẽ có hai cửa, bốn bức tường và có thể là cửa sổ. Tuy nhiên, mô hình mô tả một khu vực kèm theo với hai lối vào. Một người dẫn vào phòng trước từ bên ngoài ngôi nhà và người còn lại dẫn vào phần còn lại của ngôi nhà. Chìa khóa ở đây, là nếu bạn muốn có một phòng trước, bạn phải bao quanh một khu vực và cung cấp hai lối vào khu vực đó.

Các vấn đề điển hình với các mẫu thiết kế trong lập trình được sử dụng quá mức và niềm tin rằng chúng là những viên đạn bạc để khắc phục bất kỳ vấn đề nào. Họ không phải. Chúng là những cách để giao tiếp và suy nghĩ về những ý tưởng lập trình hữu ích. Nếu các bit cú pháp của một ngôn ngữ cụ thể là gạch và vữa, các mẫu mô tả các cách hữu ích để sắp xếp chúng để đáp ứng một nhu cầu nhất định.

Tôi xem xét thiết kế vỗ về nhiều " lời khuyên " hơn là một hợp đồng không thể thay đổi mà hoàn toàn phải tuân theo. Tại sao? Chính xác cho lý do bạn đề cập. Theo một mẫu thiết kế trong tất cả mọi thứ dẫn đến một mớ hỗn độn mã lớn đánh bại mục đích sử dụng một mẫu ở vị trí đầu tiên.

Đây là lý do tại sao tôi ghét các trang web như Thực tiễn Java . Chắc chắn một số ý tưởng là tốt, nhưng sau đó tác giả đã quyết định viết toàn bộ chương trình (cộng với một khung) theo từng mẫu thiết kế duy nhất mà ông đề cập. Tác giả cũng đã viết mỗi bài báo với những trích dẫn đáng sợ lớn khiến người đọc nghĩ rằng các thực tiễn java thực sự là khủng khiếp và nên tránh như bệnh dịch hạch.

TL; DR: Sử dụng patters thiết kế. Đừng lạm dụng chúng

Cũng seet chủ đề này trên SO. Từ một mẫu thiết kế POV khác là mã soạn sẵn để bù đắp cho những thiếu sót của phương pháp được sử dụng. Tôi không phải là một người hâm mộ của việc ăn mừng những cách giải quyết đó quá nhiều.

Tôi sẽ thích những người ở giữa. Giống như poster đã chỉ ra một cách đúng đắn, sự hiểu biết về các mẫu không giúp bạn trở thành một nhà phát triển giỏi. Mặt khác, sự hiểu biết về mô hình sẽ giúp bạn trở thành một nhà phát triển giỏi.

Hiểu mối quan hệ của các mẫu và nhìn thấy một mẫu trong một dự án (trong khi ở giai đoạn thụ thai) là điều sẽ giúp bạn trở thành một nhà phát triển giỏi.

Người ta thường nói rằng các mẫu thiết kế cung cấp một giải pháp làm sẵn cho các vấn đề lập trình. Họ là những vấn đề gì? "Làm thế nào tôi có thể thay đổi hành vi của đối tượng, nhưng cô lập các thay đổi với phần còn lại của hệ thống?"

Các mẫu GoF được công nhận để cung cấp sự cô lập (đóng gói) đó với phần còn lại của hệ thống, nhưng thường rất khó để biết phần nào của hệ thống được cung cấp thay đổi thông qua việc sử dụng các mẫu thiết kế của chúng. Thay vì tuân theo sơ đồ phân loại mà họ đề xuất (sáng tạo, hành vi và cấu trúc), tôi đã lập biểu đồ cho sự khác biệt của các mẫu và đưa ra hai sơ đồ khác để phân loại các mẫu của chúng: phân cấp đóng gói vòng đời và thành phần.

Như bạn có thể thấy từ bảng này cho hệ thống phân cấp đóng gói, các mẫu thiết kế có thể được áp dụng ở mọi cấp độ của một thành phần. Nhưng nó sẽ có ý nghĩa? Thành phần sẽ cần cung cấp biến thể hành vi ở cấp độ đóng gói được đề xuất, và mẫu có phù hợp được sử dụng cho cấp đó không? Nếu những câu hỏi này không được trả lời đúng thì các mẫu thiết kế rất có thể bị áp dụng sai. Chỉ vì một trục dọc có thể được tích hợp vào cabin của một chiếc ô tô không làm cho nó trở thành một ý tưởng thông minh.

Sử dụng một sự tương tự với tiền, một mẫu thiết kế nên được coi là một giải pháp với chi phí vốn cao nhưng chi phí vận hành thấp. Các mẫu thiết kế có giá rất cao về mặt mã hóa thêm, độ dài và trọng lượng khái niệm từ sự bổ sung mà chúng tạo ra. Họ cũng có xu hướng khóa các khía cạnh khác trong thiết kế của bạn. Ví dụ: sử dụng phương thức mẫu buộc bạn phải lập trình theo kiểu OO.

Tuy nhiên, nếu bạn cần giải quyết nhiều vấn đề liên quan chặt chẽ khác nhau theo một số cách nhỏ hoặc chắc chắn sẽ cần phải sửa đổi một đoạn mã theo một số cách cụ thể trong tương lai, chi phí trả trước có thể đáng giá vì thiết kế các mẫu thêm linh hoạt vào mã của bạn. Các sửa đổi hoặc giải pháp cho phần thứ hai của tập hợp các vấn đề liên quan chặt chẽ của bạn sẽ dễ dàng hơn rất nhiều với các mẫu hơn là không có.

Cả hai trại đều đúng - chúng là một lực lượng tốt khi được sử dụng một cách chính xác, một lực lượng xấu nếu chúng bị văng khắp nơi.

Các mẫu thiết kế có thể có sở trường thu hút bạn, nhưng điều tương tự cũng đúng với mã hóa nói chung. Thật dễ dàng để bị quyến rũ bằng cách viết hộp công cụ cuối cùng - bạn chỉ cần ghi nhớ YAGNI để ngăn bạn khỏi bị lôi cuốn, hãy cảm nhận xem ứng dụng cần bao nhiêu cấu trúc. IMO điều này chỉ tùy thuộc vào cá nhân và đánh dấu kinh nghiệm / đánh giá của họ.

Tôi nghĩ về các mẫu thiết kế không phải là thứ mà bạn luôn cố gắng áp dụng cho mã của mình. Đối với tôi, nó chủ yếu là về một ngôn ngữ chung cho các nhà phát triển. Thật dễ dàng để nói "chúng tôi theo mô hình nhà xây dựng" hơn là giải thích toàn bộ mọi thứ.

Hiện tại tôi đang đọc lại Mô hình kiến ​​trúc ứng dụng doanh nghiệp , bởi vì tôi tình cờ thấy rất nhiều mã tuân theo một trong các mẫu từ cuốn sách đó. Tôi không nghĩ rằng nó được cố ý chọn theo một trong các mẫu, nhưng nó chắc chắn sẽ hữu ích nếu bạn có thể nói " đó là một kịch bản giao dịch " và mọi người đều hiểu rõ điều đó có nghĩa là gì.

Nhưng tôi thích ý tưởng rằng bạn có thể chọn từ một danh mục các mẫu đã chuẩn bị, khi bạn thiết kế một chức năng mới hoặc một ứng dụng hoàn toàn mới. Tại sao phải phát minh lại mọi thứ nếu có giải pháp đã được chứng minh cho một số vấn đề nhất định?