Tại sao các mẫu thiết kế không được thêm vào cấu trúc ngôn ngữ?

Gần đây tôi đã nói chuyện với một đồng nghiệp đã đề cập rằng công ty của anh ta đang làm việc để thêm mẫu thiết kế MVC làm phần mở rộng PHP.

Ông giải thích rằng họ đã viết mã C để thêm Controllers, Models and Viewsvào các cấu trúc ngôn ngữ để tăng hiệu suất.

Bây giờ tôi biết rằng MVC là một mẫu thiết kế kiến ​​trúc được sử dụng rộng rãi trong các ứng dụng web, nhưng tôi vẫn phải bắt gặp các ngôn ngữ có cấu trúc ngôn ngữ cho Bộ điều khiển chẳng hạn.

IMHO tích hợp các mẫu thiết kế vào một ngôn ngữ có thể nhấn mạnh tầm quan trọng của thiết kế OO tốt.

Vì vậy, tại sao không phải là các mẫu thiết kế được sử dụng nhiều nhất (MVC, Factory, Strateg, ... vv.) Được thêm vào các cấu trúc ngôn ngữ?

Nếu câu hỏi nghe có vẻ quá rộng thì bạn chỉ có thể giới hạn câu hỏi với PHP.

Biên tập:

Tôi không ngụ ý rằng người ta phải sử dụng một mẫu thiết kế khi phát triển một dự án. Trên thực tế tôi thúc đẩy phương pháp giữ cho nó đơn giản miễn là nó hoạt động.

Mẫu thiết kế được thêm vào cấu trúc ngôn ngữ mọi lúc. Bạn đã từng nghe về mẫu thiết kế cuộc gọi chương trình con chưa? Không? Tôi cũng không. Đó là bởi vì các cuộc gọi chương trình con, vốn là một mẫu thiết kế vào đầu những năm 1950 đã được thêm vào các ngôn ngữ ngay lập tức. Ngày nay, chúng thậm chí còn hiện diện trong bộ hướng dẫn mã máy của CPU.

Những gì về mẫu thiết kế vòng lặp ? Các khi Loop Thiết kế mẫu? Mẫu thiết kế Switch ? Mẫu thiết kế đối tượng ? Mẫu thiết kế lớp học ? Tất cả những thứ này đã được thêm vào một số ngôn ngữ.

Một số trong số họ là. Ví dụ, các trình vòng lặp là tính năng ngôn ngữ trong nhiều ngôn ngữ và các thư viện tiêu chuẩn của chúng (xin chào, foreach và lợi nhuận). Observer cũng thường xuyên có mặt dưới dạng các sự kiện (không phải trong PHP - bạn phải tự quản lý đăng ký gọi lại). Lệnh là tính năng cốt lõi trong WPF.

Nhiều người khác sẽ không thực sự được hưởng lợi từ hỗ trợ ngôn ngữ (và sẽ làm cho ngôn ngữ trở nên cồng kềnh hơn) - bạn sẽ đơn giản hóa Bộ điều khiển như thế nào nếu bạn có thể thiết kế tính năng ngôn ngữ cho họ? Là các lớp, chúng được hưởng lợi từ tất cả các cơ sở hạ tầng đã có mặt để hỗ trợ các lớp - bạn có thể khởi tạo chúng, chuyển chúng xung quanh và ví dụ đơn vị kiểm tra chúng như bất kỳ đối tượng nào khác.

Thành phần duy nhất của MVC mà IMO có thể hưởng lợi từ một số loại hỗ trợ ngôn ngữ là View (với một số công cụ tạo khuôn mẫu chính thức) - và nó đã được hỗ trợ trong PHP - bạn có thể tự động tạo và tải các tập lệnh PHP (thường có một số loại tiền xử lý được sử dụng làm mẫu).

Điều tương tự cũng áp dụng cho phương pháp xuất xưởng - bạn sẽ đơn giản hóa điều đó như thế nào, nếu bạn có thể có bất kỳ loại tính năng ngôn ngữ nào bạn muốn? Một tính năng mà một số ngôn ngữ (như C ++) thiếu là khả năng xây dựng đối tượng từ tên loại này, nhưng hầu hết các ngôn ngữ cấp cao hơn có thể làm điều này (và thậm chí không cần thiết phải tạo các phương thức xuất xưởng hữu ích). Ngoài ra, tất cả những gì bạn cần là có thể tạo ra một phương thức khởi tạo và trả về và phản đối.

Một số mẫu thiết kế thực sự được thêm vào dưới dạng cấu trúc ngôn ngữ - chúng không được nhận dạng như vậy bởi vì mọi người bắt đầu coi chúng là "cú pháp" khi chúng được xây dựng. Xử lý ngoại lệ trong Java là một ví dụ tốt - nhiều người sẽ mã hóa một cái gì đó tương tự rõ ràng như một mẫu thiết kế nếu nó không phải là một phần của cú pháp cốt lõi.

Nhưng để tập trung vào câu hỏi - có nhiều lý do khiến bạn không muốn thêm quá nhiều mẫu thiết kế vào một ngôn ngữ:

• Không cần thiết phải thêm chúng dưới dạng cấu trúc ngôn ngữ - tất cả các mẫu thiết kế có thể được thực hiện theo những cách khác
• Nó sẽ làm phức tạp ngôn ngữ - đây là một ý tưởng tồi vì nó làm cho ngôn ngữ khó học hơn, làm cho trình biên dịch và công cụ khó viết hơn
• Phương pháp thực hiện thay thế tồn tại cho nhiều mẫu thiết kế. Chọn một cách tiếp cận và ban phước cho nó như một phần của ngôn ngữ cốt lõi có thể sẽ khiến mọi người sử dụng cách tiếp cận đó hơn các cách tiếp cận khác (có thể tốt hơn nhiều trong một số trường hợp)
• Quá phụ thuộc vào các mẫu thiết kế có lẽ là một ý tưởng tồi trong mọi trường hợp - các nhà thiết kế ngôn ngữ có thể nhận ra rằng họ không nên khuyến khích họ hơn nữa.

Ngoài ra, nếu bạn sử dụng một ngôn ngữ đủ mạnh với khả năng lập trình siêu dữ liệu (ví dụ: Lisp), việc tự mở rộng ngôn ngữ để thực hiện bất kỳ mẫu thiết kế nào sẽ trở nên tương đối đơn giản . Bạn không cần bất kỳ mẫu nào trong ngôn ngữ cốt lõi nếu dễ dàng thêm mẫu của riêng bạn với macro 5 dòng.

Tại sao các mẫu thiết kế không được sử dụng nhiều nhất (MVC, Factory, Strateg, ... vv.) Được thêm vào cấu trúc ngôn ngữ?

Hầu hết các mẫu này có thể được thực hiện trong hầu hết các ngôn ngữ lập trình mà không cần hỗ trợ ngôn ngữ cụ thể. Lấy ví dụ MVC trong Java:

• Bạn có thể mã nó trực tiếp.
• Bạn có thể triển khai nó bằng cách sử dụng một trình tạo ứng dụng ... và chăm sóc rất nhiều nồi hơi khác cùng một lúc.
• Bạn có thể thực hiện nó bằng cách sử dụng các lớp thư viện "khung".
• Bạn có thể thực hiện nó bằng cách sử dụng các chú thích và xử lý chú thích tĩnh hoặc thời gian chạy.

Với tất cả các tùy chọn này, có rất ít giá trị trong việc mở rộng trực tiếp ngôn ngữ. Và có một số "nhược điểm":

• Nó sẽ có xu hướng làm lộn xộn cú pháp ngôn ngữ, (được cho là) ​​làm cho cuộc sống khó khăn hơn cho các lập trình viên mới làm quen.
• Nó sẽ có xu hướng làm cho đặc tả ngôn ngữ lớn hơn và phức tạp hơn, gây khó khăn hơn cho những người thực hiện ngôn ngữ. (Và, tất nhiên, thông số kỹ thuật càng lớn thì càng có nhiều khả năng xảy ra lỗi và sự không nhất quán.)
• Sẽ luôn có áp lực để thêm một mô hình khác ... dẫn đến các vấn đề / mối quan tâm với sự ổn định ngôn ngữ.
• Bằng cách hỗ trợ các mô hình cụ thể trong ngôn ngữ, bạn khó dây cụ thể cách hỗ trợ các mô hình, trong đó có thể không phù hợp với một số ứng dụng.

Họ đang.

Các hàm là một mẫu thiết kế trong mã lắp ráp trước khi chúng trở thành một cấu trúc ngôn ngữ trong C.

Các hàm ảo là một mẫu thiết kế trong C trước khi chúng trở thành cấu trúc langiage trong C ++.

Tuy nhiên, có một sự đánh đổi. Nếu mô hình liên quan đến việc sản xuất mã soạn sẵn (thậm chí một vài từ khóa), thì đó là một dấu hiệu cho thấy đó sẽ là một tính năng ngôn ngữ hữu ích. Nhưng nếu mô hình đơn giản và rõ ràng, ví dụ. C "for (int i = 0; i <10; i ++)", mọi người vẫn viết nó theo cách tương tự, nhưng nó không dài hơn đáng kể so với "for i = 0 đến 10" và có lợi thế đáng kể Rõ ràng làm thế nào để thay đổi nó để làm cho một vòng lặp hơi khác nhau.

Đọc cuốn sách 'băng đảng bốn người' và nó sẽ trở nên rõ ràng rằng:

1. Các mẫu thiết kế trong cuốn sách thực sự là các quy ước smalltalk nổi tiếng được mã hóa bằng các ngôn ngữ OO khác.
2. Do đó, các mẫu đó không thể được đưa vào ngôn ngữ OO - nó sẽ được triển khai lại smalltalk bên trong các ngôn ngữ đó - tốt hơn là sử dụng trực tiếp smalltalk
3. Tại sao các mẫu thiết kế hữu ích là vì chúng nhấn mạnh vai trò của ngôn ngữ hiện đang sử dụng và tập trung vào các vấn đề khác ngoài cú pháp. Mã hóa các mẫu bên trong ngôn ngữ sẽ làm mất tính năng này của các mẫu thiết kế.
4. Vấn đề thực sự trong câu hỏi trên là nó bỏ lỡ vấn đề là viết phần mềm không chỉ là học ngôn ngữ. Điều quan trọng là phải có đủ khoảng cách với ngôn ngữ đang trực tiếp cung cấp và tập trung vào các yêu cầu hiện tại.

Bởi vì các mẫu thiết kế được thực hiện hoàn toàn tốt với mã người dùng. Ví dụ của anh ta chỉ xảy ra vì đó là PHP - nhưng nếu bạn thực sự cần hiệu suất, bạn sẽ chỉ làm việc bằng ngôn ngữ khác hoặc nhận HipHop hoặc một cái gì đó.

Các tính năng ngôn ngữ rất phức tạp, cả để chỉ định và thực hiện và không thể tạo ra một mục đích duy nhất cho mục đích duy nhất là "Thành ngữ hiện tại là X". Bạn hầu như không lưu bất kỳ mã người dùng có ý nghĩa nào, và không có gì.

Ơ, câu hỏi cũ nhưng tôi không đồng ý với rất nhiều câu trả lời tùy thuộc vào nơi bạn đặt "Mẫu thiết kế" trên mặt số ngữ nghĩa bao gồm cả câu được chấp nhận.

Theo nghĩa của cuốn sách Mẫu thiết kế GoF, tôi muốn nói nó phụ thuộc. Ví dụ, MVC (không thực sự là mẫu GoF nhưng phù hợp với khuôn đó), hoàn toàn không phù hợp để thể hiện dưới dạng cấu trúc ngôn ngữ để tiêu thụ hàng loạt (mặc dù nó có thể có ý nghĩa đối với một dự án PHP cụ thể). Là một mô hình kiến ​​trúc, có các biến thể liên tục về chủ đề và rất nhiều cách hiểu hoàn toàn hợp pháp về nó cho các trường hợp khác nhau (mặc dù nhiều người đã rời xa MVC nhưng có lẽ họ không nên gọi nó là MVC nữa). Chẳng hạn, trên web, rào cản http làm cho nó phù hợp một chút khó xử tùy thuộc vào việc bạn có đang cố gắng đưa phía khách hàng (không nghi ngờ gì nữa) vào phương trình và những gì bạn đang xem xét "quan điểm" từ nhiều hơn thích hợp nghiêm ngặt quan điểm phía máy chủ.

Mặt khác, Iterator là một khái niệm có tính khái quát cao, có thể được áp dụng theo nhiều cách khác nhau cho nhiều loại cấu trúc khác nhau.

Trường hợp nên rút ra xem liệu thứ gì đó có thuộc về thiết kế ngôn ngữ cốt lõi hay không, ngay cả trong ngôn ngữ cụ thể của máy chủ, IMO, là điểm mà một thứ gì đó vượt qua khỏi đường để giúp dễ dàng thực hiện một số lượng không thể đếm được dễ dàng hơn so với việc thực hiện một điều cụ thể quá mức nhưng được triển khai rộng rãi như một mẫu kiến ​​trúc cho bạn.