Các mẫu thiết kế có thực sự cần thiết hiện nay?

Tôi đã đọc "Coders tại nơi làm việc" và đã phải đối mặt với thực tế là một số chuyên gia được phỏng vấn trong cuốn sách không quá nhiệt tình về các mẫu thiết kế.

Tôi nghĩ rằng có 2 lý do chính cho việc này:

1. Các mẫu thiết kế buộc chúng ta phải suy nghĩ theo thuật ngữ của họ. Nói cách khác, gần như không thể phát minh ra thứ gì mới (có thể tốt hơn).

2. Các mẫu thiết kế không tồn tại mãi mãi. Ngôn ngữ và công nghệ thay đổi nhanh chóng; do đó, các mẫu thiết kế cuối cùng sẽ trở nên không liên quan.

Vì vậy, có lẽ điều quan trọng hơn là học cách lập trình đúng mà không có bất kỳ mô hình cụ thể nào và không học chúng.

Vấn đề cũng là thông thường khi mọi người đối mặt với một vấn đề và họ không có nhiều thời gian, họ cố gắng sử dụng một mô hình. Điều này có nghĩa là sao chép và dán mã hiện có vào dự án của bạn với những thay đổi nhỏ để làm cho nó hoạt động. Khi đến lúc phải thay đổi hoặc thêm một cái gì đó, một nhà phát triển không biết bắt đầu từ đâu vì đó không phải là mã của anh ta và anh ta không quen thuộc lắm với nó.

Đối với tiền của tôi, tôi nghĩ mọi người đều thiếu quan điểm của các mẫu thiết kế. Thật hiếm khi tôi ngồi tự hỏi tôi nên sử dụng mẫu nào trong một tình huống nhất định. Ngoài ra, tôi đã sử dụng hầu hết các mẫu đó từ lâu trước khi tôi biết chúng có tên.

Sức mạnh của các mẫu thiết kế là trong giao tiếp. Tôi nói "sử dụng Chiến lược cho việc đó" nhanh hơn nhiều so với mô tả chi tiết những gì tôi đang đề xuất. Chúng ta sẽ dễ dàng hơn nhiều khi tranh luận về lợi ích của các mô hình miền béo so với các tập lệnh giao dịch nếu tất cả chúng ta đều biết hai thuật ngữ đó có nghĩa gì. Và như vậy.

Và mạnh mẽ nhất, nếu tôi đã đặt tên một lớp FooBuilder thì bạn sẽ biết rằng tôi đang sử dụng mẫu Builder để tạo Foo của mình.

Ngay cả khi bạn không biết tôi đang nói về điều gì khi tôi nói "Mẫu quan sát là lý tưởng cho điều đó", bạn sẽ có thể tắt và google nó khá dễ dàng.

Theo nghĩa đó, sức mạnh của các mẫu thiết kế sẽ không bao giờ phai.

Các mẫu thiết kế là sự gia tăng sức mạnh biểu cảm của ngôn ngữ chung mà chúng ta sử dụng như những người làm phần mềm. Ngôn ngữ chung này không cần thiết, nhưng nó làm cho nhiều giải pháp chung cho các vấn đề trở nên dễ dàng hơn và nhanh hơn để diễn đạt. Ví dụ, nói về Singletons dễ dàng hơn nhiều so với việc nói về "các lớp mà chúng ta chỉ có một trường hợp nhưng không thể được tạo thành tĩnh và toàn cầu".

Các giải pháp mà các mẫu thiết kế cung cấp rất hữu ích, nhưng chúng là các giải pháp mà có lẽ bạn đã nghĩ đến nếu bạn phải đối mặt với các vấn đề mà chúng giải quyết. Một mức độ trưởng thành nhất định là cần thiết để hiểu các mẫu thiết kế - nếu bạn chưa bao giờ phải giải quyết vấn đề, bạn sẽ không thấy giá trị hoặc lợi ích trong giải pháp.

Các mẫu phục vụ hai mục đích chính:

• Giải quyết căng thẳng có thể dự đoán được : Các mô hình được thiết kế để giải quyết một tập hợp căng thẳng nhất định theo cách được biết là hoạt động. Kent Beck, tác giả của Mô hình thực hành tốt nhất Smalltalk , mô tả các mô hình như một cách để lặp lại quyết định mà một chuyên gia sẽ đưa ra trong hoàn cảnh tương tự. Miễn là các căng thẳng vẫn giữ nguyên (và chúng thường làm), các mẫu giải quyết chúng sẽ vẫn hữu ích.

• Hệ số nhân lực truyền thông : Các mẫu cho phép chúng ta nói nhiều với một chút. Họ tận dụng một tập hợp nhỏ các khái niệm mạnh mẽ, được hiểu rõ, có thể áp dụng trong nhiều không gian vấn đề khác nhau. Câu trả lời của @ pdr đã chết về giá trị giao tiếp của các mẫu.

Tôi nghĩ rằng sự khẳng định rằng các mẫu thiết kế cản trở sự đổi mới là hoàn toàn sai. Bạn nên biết bất cứ nơi nào đã tồn tại để bạn không cần phải phát minh lại bánh xe. Đối với tạm thời, các mẫu tổng thể áp dụng cho các hệ thống OOP và không được liên kết với bất kỳ nền tảng hoặc ngôn ngữ cụ thể nào.

Bây giờ, điều tôi không thích khi mọi người nói về các mẫu là một số người có một nỗi ám ảnh với họ. Tôi đã từng có một khách hàng yêu cầu tôi "bao gồm ít nhất hai mẫu nữa" (WTF?!) Vì thiếu từ thông dụng trong mã của tôi, nó trông không đủ phức tạp.

Có lẽ khái niệm chống mẫu là mầm. Tôi không nghĩ việc nghiên cứu các mẫu thiết kế là bước quan trọng để trở thành một kỹ sư phần mềm. Thiết kế phần mềm rất quan trọng, thường được dành làm đặc quyền của kiến ​​trúc sư phần mềm trong một dự án, nhưng thực tế lại có một cái gì đó có thể bị cản trở bởi sự đồng thuận trong nhóm "câu tục ngữ".

Nhưng các mẫu thiết kế và các mẫu chống tạo thành một nguồn lực cho các cuộc thảo luận đó. Người ta cần đánh giá cao những bài học về những thứ hoạt động tốt (hoặc không) và cách tận dụng (hoặc giảm thiểu) hậu quả của các lựa chọn thiết kế. Một nhóm tốt có thể đưa ra vốn từ vựng của riêng họ cho các cuộc thảo luận như vậy, nhưng thực sự không có gì xấu khi tham khảo các tiêu chuẩn defacto được thực hiện bởi các tác giả đã từng ở đó, đã làm điều đó.

Có hai loại mẫu thiết kế:

1. Các mẫu phổ quát , nhiều hơn về cách tổ chức các chương trình phức tạp để bạn có thể hiểu chúng. Chúng sẽ không biến mất, mặc dù nhiều ví dụ về chúng có thể được phát hiện.
2. Các mẫu tình huống , bị ràng buộc vào các lực cụ thể do các ràng buộc (ví dụ, ngôn ngữ lập trình) mà khi các lực đó thay đổi, chúng trở nên không liên quan.

OK, có thể cho rằng tất cả các mô hình là hơi tình huống, nhưng với một số lực lượng đến từ thế giới thực và với các lực lượng khác là từ các công cụ. Công cụ thay đổi nhanh hơn nhiều so với thế giới thực.

Đọc về các mẫu thiết kế cũng giống như học toán thay vì phát minh lại chúng. Không có gì ngăn cản bạn tiến bộ vượt bậc trong một lĩnh vực nhất định một khi bạn có một sự hiểu biết vững chắc về những gì đã đi trước. Bạn có nghĩ Rieman không bao giờ đọc Euclid?

Có lợi ích khi thiết kế các mẫu khi họ giảm lượng thời gian mà đồng nghiệp hoặc khách hàng của bạn dành để suy nghĩ "Công việc này hoạt động như thế nào?". Mặc dù không có ý nghĩa gì trong việc thực thi một tiêu chuẩn vì mục đích tiêu chuẩn hóa, nhưng nếu có một cách phổ biến và được hiểu rõ để làm một cái gì đó, bất cứ khi nào một lập trình viên tìm kiếm mô hình đó mong muốn tìm thấy nó và thực hiện, bạn đã thực hiện công việc của họ và của bạn dễ dàng hơn

Tôi tin rằng nhóm bốn người tự phân loại các mẫu thiết kế là

một giải pháp chung cho một vấn đề thường xảy ra *

Vì vậy, có, các mô hình có liên quan khi cùng một loại vấn đề xảy ra. Và điều này đưa chúng ta đến một vấn đề với thuật ngữ "Mẫu thiết kế". Một mô hình là một cái gì đó dễ nhận biết xảy ra lặp đi lặp lại. Vì vậy, trong thực tế không có một mẫu thiết kế, có một mẫu của các vấn đề.

Một số ngôn ngữ lập trình có thể có giải pháp riêng cho một số vấn đề đó. Bản thân cuốn sách "Mẫu thiết kế" đã đề cập rằng mẫu khách truy cập ít có giá trị nếu bạn đang sử dụng CLOS, vì đa công văn được CLOS hỗ trợ, đây là vấn đề mà mẫu Khách truy cập đang cố gắng giải quyết.

Ngoài ra, .NET framework có một cơ chế xây dựng sự kiện để xuất bản các sự kiện cho nhiều người nghe, làm cho mẫu Observer ít liên quan hơn trong ngữ cảnh này.

Sự thay đổi từ ứng dụng máy tính để bàn sang ứng dụng web ** cũng thay đổi loại vấn đề lập trình mà chúng ta phải giải quyết. Nhiều mẫu trong cuốn sách "Mẫu thiết kế" có liên quan đến các ứng dụng máy tính để bàn, nhưng không nhiều cho các ứng dụng web. Tất nhiên, với các ứng dụng trang đơn, các mẫu này có thể có liên quan một lần nữa ở phía máy khách.

Nhưng các mẫu thiết kế và sách như "Mẫu thiết kế" hoặc "Mẫu kiến ​​trúc ứng dụng doanh nghiệp" có giá trị rất lớn khi bạn là một lập trình viên mới làm quen và lần đầu tiên phải đối mặt với một loại vấn đề mới; vì tôi là lần đầu tiên tôi được yêu cầu thực hiện chức năng Hoàn tác. Nếu không có trong cuốn sách "Các mẫu thiết kế", thì việc triển khai của tôi có thể giống như lưu trữ một ảnh chụp nhanh dữ liệu sau mỗi hoạt động thay đổi trạng thái *** - một cách tiếp cận rất dễ bị lỗi và kém hiệu quả.

Vì vậy, có, một số mô hình trở nên ít liên quan hơn theo thời gian và khi bạn trở thành một lập trình viên có kinh nghiệm, bạn nghĩ ít hơn về chúng. Nhưng đối với một người mới, chúng có giá trị, miễn là bạn nhớ rằng chúng là phương tiện để giải quyết vấn đề - và không phải là một nhiệm vụ để sử dụng càng nhiều càng tốt.

* trích dẫn có thể không chính xác 100% vì nó được lấy từ bộ nhớ

** theo kinh nghiệm của tôi, việc các doanh nghiệp lựa chọn cơ chế phân phối web cho các ứng dụng kinh doanh nội bộ trở nên rất phổ biến.

*** sau khi học lập trình chức năng và cấu trúc dữ liệu chức năng, thì đó thực sự có thể là cách tôi sẽ giải quyết nó ngày hôm nay.

Việc tuân thủ nghiêm ngặt các mẫu thiết kế có thể gây bất lợi - các mẫu là giải pháp được ghi lại cho các vấn đề phổ biến, nhưng chúng không phải là hướng dẫn sử dụng. Tuy nhiên, chỉ vì chúng được thảo luận dài và trong một số trường hợp, được áp dụng bên ngoài các miền có vấn đề hiệu quả không có nghĩa là chúng không có giá trị gì. Chúng là một tập hợp các nguyên tắc - gọi nó là khung - để rút ra khi thiết kế kiến ​​trúc của chương trình, cho phép kiến ​​trúc sư tạo ấn tượng về cách anh ấy / cô ấy muốn thấy giải pháp hoạt động. Một nhóm phát triển tốt xem chúng như một cơ sở cho chức năng, chứ không phải là một đặc tả chức năng.