Vì vậy, các mẫu thiết kế có thiếu tính năng ngôn ngữ không? [đóng cửa]

Tôi đã thấy, ở đây trên các lập trình viên, câu trả lời cho câu hỏi này: Làm thế nào để suy nghĩ về các mẫu thiết kế và thực tiễn OOP thay đổi trong các ngôn ngữ động và gõ yếu? Ở đó tôi tìm thấy một liên kết đến một bài viết với tiêu đề thẳng thắn: Các mẫu thiết kế thiếu các tính năng ngôn ngữ . Nhưng nơi tôi tìm thấy những đoạn mà đối với tôi có vẻ rất hấp dẫn và điều đó có thể được xác minh dựa trên kinh nghiệm được đưa ra, có một sự khích lệ cho điều đó, như:

PaulGraham nói "Peter Norvig nhận thấy rằng 16 trong số 23 mẫu trong Mẫu thiết kế là 'vô hình hoặc đơn giản hơn' ở Lisp."

hoặc một câu khác xác nhận những gì tôi thấy gần đây với những người đang cố gắng mô phỏng các lớp trong JavaScript:

Tất nhiên, không ai từng nói về mẫu "hàm" hoặc mẫu "lớp" hoặc nhiều thứ khác mà chúng ta cho là vì hầu hết các ngôn ngữ cung cấp cho chúng dưới dạng các tính năng tích hợp. OTOH, lập trình viên trong một ngôn ngữ hoàn toàn PrototypeOrientsL Language? cũng có thể thấy thuận tiện khi mô phỏng các lớp với các nguyên mẫu ...

Tôi cũng đang xem xét rằng các mẫu thiết kế là một công cụ hoa hồng . Bởi vì ngay cả với kinh nghiệm hạn chế của tôi khi tham gia xây dựng các ứng dụng, tôi có thể xem như là một mô hình chống ( không hiệu quả và / hoặc phản tác dụng e), buộc một nhóm PHP nhỏ phải học các mẫu GoF cho Ứng dụng mạng nội bộ vừa và nhỏ. Tôi biết rằng quy mô, phạm vi và mục đích có thể xác định những gì hiệu quả và / hoặc hiệu quả, nhưng tôi vẫn không tìm thấy một tổng quan kỹ thuật về điều đó.

Tôi đã thấy các ứng dụng thương mại nhỏ có chức năng trộn lẫn với OOP và vẫn có thể duy trì được và tôi không biết liệu nhiều người có cần sử dụng python để viết một singleton hay không, nhưng đối với tôi, một mô-đun đơn giản cũng làm điều tương tự.

Vì vậy, có những nghiên cứu, bài báo đầy đủ hoặc hình thức giải trình khác có tính đến các mẫu thiết kế so với cách giải quyết so với những cách đơn giản hơn để làm điều đó, hoặc thay thế bằng các tính năng ngôn ngữ?

programming-languages design-patterns

— Eduard Florinescu
nguồn

Sẽ là một sai lầm khi chấp nhận bất cứ điều gì mà Paul Graham nói về chủ đề ngôn ngữ lập trình là "khách quan và thực tế".

— Mason Wheeler

Tôi không có xu hướng không đồng ý với Paul Graham, nhưng @MasonWheeler nói đúng, các nhà truyền giáo rất tuyệt vời vì nhiều lý do, nhưng không phải vì tính khách quan của họ.

— Jimmy Hoffa

@JimmyHoffa: Nói chung không phải là "nhà truyền giáo". Tôi có vấn đề với lịch sử lâu dài của Graham về việc đăng các tài liệu lố bịch thường xuyên mâu thuẫn với chính mình hoặc các nguồn của anh ấy và cố gắng biến toàn bộ sự việc trở nên nhất quán. Bất kể bạn đang ủng hộ điều gì, đó là một cách khủng khiếp để nói về nó, và có một chút kinh hoàng với tôi rằng mọi người thực sự lắng nghe anh ấy.

— Mason Wheeler

Sẽ rất tuyệt khi xem một số nghiên cứu, nhưng nếu bạn đã từng sử dụng các ngôn ngữ chức năng hiện đại - bạn đã biết các mẫu thiết kế GOF lỗi thời như thế nào và không cần phải có số để chứng minh thêm . (Mặc dù, chúng rất quan trọng vào năm 1990, không còn nghi ngờ gì nữa).

— c69

@DanielB, mọi mô hình cụ thể sẽ thất bại, vì thực tế phức tạp hơn nhiều so với bất kỳ mô hình nào có thể xảy ra. Do đó, mỗi và mọi vấn đề đều xứng đáng với mô hình và mô hình cụ thể của miền.

— SK-logic

Tôi không biết về bất kỳ cuộc thảo luận hoặc nghiên cứu chuyên sâu nào có tính đến tất cả những điều đó.

Điều đó nói rằng, toàn bộ lập luận của "các mẫu thiết kế chỉ là vá các tính năng bị thiếu trong các ngôn ngữ OO" theo tôi là hơi mỏng. Đúng, một số mẫu thiết kế chính xác là như vậy, chúng lấp đầy một số khoảng trống phổ biến thậm chí không tồn tại trong một số ngôn ngữ khác X. Đây thường là các mẫu thiết kế đơn giản, cấp thấp của bạn, như một số / nhiều mẫu gốc trong sách GoF.

Nhưng các mẫu thiết kế vượt xa những mẫu đơn giản đó và gọi chúng là các tính năng ngôn ngữ bị thiếu kéo dài trí tưởng tượng. Lướt qua danh mục các mẫu ứng dụng doanh nghiệp của Fowler và suy nghĩ xem nó sẽ như thế nào nếu đó là tất cả các định nghĩa cốt lõi của ngôn ngữ. Tôi đoán bạn sẽ kết thúc với ngôn ngữ dành riêng cho tên miền ( DSL ) cho các ứng dụng doanh nghiệp (và một ngôn ngữ rất phức tạp, tại đó).

Vì vậy, đây là điều thực sự - các mẫu thiết kế là cách để đưa ra các giải pháp có thể sử dụng lại cho các vấn đề cụ thể (thường được áp dụng trong một ngôn ngữ chung, đa mục đích). Đây là nơi giao tiếp cũng đến. Nếu bạn nói với tôi "chúng tôi sử dụng Hồ sơ hoạt động", tôi đã biết khá nhiều về ứng dụng của bạn, mà không mất vài phút để thảo luận về các phương pháp khác nhau. Vì vậy, có, các mẫu thiết kế làm lỗ hổng trong đặc tả ngôn ngữ. Đó là tất cả những gì họ làm? Không, không phải bằng một cú sút xa.

Biên tập:

Theo một cách nào đó, điều tôi đang nói là các mẫu cho phép các học viên OO suy nghĩ ở cấp độ cao hơn và gần như xây dựng một loại DSL cho môi trường của họ, trong khi vẫn nằm trong cú pháp ngôn ngữ của họ. Và vâng, tôi đã thấy những gì xảy ra khi bạn áp dụng chúng ở mọi nơi (xem: AbstractSingletonProxyFactoryBean , vâng, nó tồn tại), hoặc nghĩ rằng chúng là một loại đạn bạc. Vấn đề là trong khi họ mất nhiều thời gian để thực sự thoải mái, họ được cho là thực sự hạ thấp độ phức tạp bằng cách làm cho mọi thứ có thể dự đoán / dễ hiểu ở mức cao. Điều này rất khác với việc trở thành một bộ vá cho những thất bại trong ngôn ngữ của bạn.

Chỉnh sửa 2 - đã thêm ví dụ đối chiếu AbstractSingletonProxyFactoryBean để tạo ra một số niềm vui tại các mẫu. Để hoàn toàn công bằng, khi nhìn từ đèn AOP, ngay cả ví dụ ngược này cũng có thể phòng thủ được.

— Daniel B
nguồn

(+1) và chấp nhận vì bạn đã thu hẹp tìm kiếm của tôi trên DSL và các mẫu ứng dụng. Rất chu đáo, và bạn có thể vui lòng mở rộng hoặc liên kết cho người đọc có thể trong ngoặc đơn ít nhất một trong những từ viết tắt DSL mà tôi cho rằng nó có nghĩa là Ngôn ngữ dành riêng cho miền.

— Eduard Florinescu

@EduardFlorinescu cảm ơn, tôi đã cập nhật các liên kết cho DSL.

— Daniel B

Tôi cũng tìm thấy bài viết này xác nhận một phần câu trả lời của bạn trong trường hợp này với Groovy ibm.com/developerworks/java/l

— Library / j-eaed7 / index.html

@EduardFlorinescu điều đó rất thú vị, mặc dù tôi không chỉ đề cập đến mẫu phiên dịch cụ thể; thay vào đó, tôi có nghĩa là nhiều mẫu có thể khá cụ thể theo miền và trở nên gần như thành ngữ cho các nhà phát triển trong miền đó. Theo nghĩa đó, chúng trở thành một loại DSL và không mất nhiều công sức để hiểu và sử dụng. Ví dụ: khi tôi đọc qua một mẫu lệnh (một ví dụ cụ thể không thuộc miền), tôi biết mã soạn sẵn nào tôi có thể bỏ qua một cách an toàn và không mất nhiều công sức. Nhưng cảm ơn vì liên kết thú vị, dù sao.

— Daniel B