Các mẫu thiết kế không OOP? [đóng cửa]

70

Tôi chỉ nghe thấy thuật ngữ "mẫu thiết kế" được sử dụng cho mã hướng đối tượng và các mẫu GoF chỉ bao gồm các mẫu thiết kế OOP, nhưng các mẫu thiết kế là giải pháp tao nhã cho các vấn đề lập trình thường xảy ra, phải không? Không có gì trong đó nói rằng họ phải giới hạn ở OOP, phải không?

Tôi muốn xem một số ví dụ về các mẫu thiết kế bên ngoài lĩnh vực lập trình hướng đối tượng. Bạn có cái nào không Làm như vậy thậm chí tồn tại (không có cuốn sách, như cuốn sách GoF, nhất thiết phải được viết, chúng chỉ nên được sử dụng; như vậy là đủ)?

Chúng có thể đặc trưng cho một số ngôn ngữ lập trình, nhưng các mẫu chung (cấp độ mô hình) được ưa thích, của các mô hình khác hơn các mô hình hướng đối tượng.

design-patterns

— Anto
nguồn

8

Tôi nghĩ rằng sự bất đồng lớn nhất mà các sách mẫu thiết kế phổ biến đã làm là tạo ra một loạt người tin rằng các mẫu chỉ áp dụng cho các ngôn ngữ hướng đối tượng. Các mẫu sáng tạo gây tranh cãi, nhưng hầu hết các mẫu khác đều có thể và được triển khai trong mọi ngôn ngữ không định hướng đối tượng mọi lúc. Tôi chắc chắn rằng tác dụng phụ này không phải là ý định của tác giả, nó không phải là tác dụng phụ.

— Pemdas

14

Chà, các đối tượng là một mẫu thiết kế trong các ngôn ngữ không phải OO :)

— back2dos

1

thậm chí tệ hơn, sách mẫu đã tạo ra cả một nhóm người tin rằng mọi vấn đề và mọi vấn đề nên được giải quyết bằng cách áp dụng một mẫu cụ thể (thường là mẫu cuối cùng được dạy bởi một giáo viên trường nào đó cũng tin như vậy).

— jwenting

25

Hãy xem loạt bài về Mẫu thiết kế hạt nhân Linux. Các bài viết có liên quan đến một ngôn ngữ không hướng đối tượng (C) và tôi tin rằng chúng được viết tốt:

— sakisk
nguồn

Họ đang sử dụng phương pháp hướng đối tượng mặc dù.

— Kais 28/11/18

12

Trên thực tế, đó là nghịch lý - một trong những mẫu Non-OO phổ biến nhất là ... "Class".

Vì OO được phát minh bằng các ngôn ngữ không phải OO, nên các nhà phát triển phải mô phỏng nó (và họ đang thực hiện ngay cả bây giờ) - vì vậy mô hình đã ra đời. LISP và C là ví dụ về điều này.

Nhưng hãy nghe lời khuyên của tôi: Đừng mắc lỗi phổ biến - đừng chỉ sử dụng các mẫu vì nó hay , bạn cần những lý do nghiêm trọng để biện minh cho việc sử dụng mẫu (ít nhất là các mẫu OO).

Lấy mẫu lệnh làm ví dụ - mặc dù nó rất hay và nó tách người gọi khỏi máy thu, nhưng nó không nên được sử dụng trừ khi bạn thực sự cần điều đó - bởi vì các thao tác nên được diễn đạt bằng động từ - có nghĩa là phương thức. Và sử dụng các lệnh tất cả các nơi bạn sẽ kết thúc với một loạt các OO-lambdas phi tập trung hoàn toàn -> điều tương tự sẽ đúng với rất nhiều Chiến lược.

— Kamil Tomšík
nguồn

11

"Mẫu thiết kế" thực sự là một uyển ngữ cho "cách giải quyết". Các mẫu thiết kế đã được phát minh để khắc phục những thiếu sót và sai sót trong các ngôn ngữ OO . Ví dụ, lấy mẫu lặp, cuối cùng dẫn đến việc giới thiệu các bộ sưu tập trong Java. Groovy đã loại bỏ nhiều mẫu hơn bằng cách chuyển đổi chúng thành các tính năng ngôn ngữ: Bạn không còn cần mẫu trang trí nữa vì bạn có thể thêm các phương thức vào các lớp hiện có trong Groovy.

Điều này có nghĩa là bạn có thể tìm thấy các mẫu thiết kế ở khắp mọi nơi. Trong thực tế, mọi "thực hành tốt nhất" có thể được coi là một hình thức đơn giản của một mẫu thiết kế.

— Aaron Digulla
nguồn

9

Đã đồng ý! Từ Paul Graham : "Ví dụ, trong thế giới OO, bạn nghe rất nhiều về" mẫu ". [...] Khi tôi thấy các mẫu trong các chương trình của mình, tôi coi đó là dấu hiệu của sự cố. Hình dạng của chương trình sẽ phản ánh Chỉ có vấn đề cần giải quyết. Bất kỳ sự đều đặn nào khác trong mã là một dấu hiệu, đối với tôi, ít nhất, tôi đang sử dụng các khái niệm trừu tượng không đủ mạnh - thường là tôi đang tạo ra các bản mở rộng của một số macro mà tôi cần phải viết. "

— Andres F.

7

Tôi không đồng ý với một mẫu thiết kế là một cách giải quyết. Hai là đối lập. Một cách giải quyết là một bản vá ngắn hạn được đặt cùng nhau để vượt qua một trở ngại cụ thể. Mẫu thiết kế là giải pháp tái sử dụng lâu dài. Mục đích của mẫu trang trí là thêm chức năng 'mà không' sửa đổi lớp. Bạn có thể đặt các trang trí khác nhau lên một đối tượng mà không cần đối tượng biết về nó.

— Despertar

Lý do tại sao các mẫu được coi là "cách giải quyết" là vì trang trí một đối tượng nên là một đặc điểm của ngôn ngữ. Thay vào đó, chúng ta phải viết nhiều, nhiều dòng mã để thực hiện điều này. Lấy ví dụ, mẫu lặp đã trở thành một phần của nhiều ngôn ngữ hiện đại. Đối với các ngôn ngữ OO cũ hơn, bạn cần phải nhảy qua một vài vòng để mô phỏng chúng.

— Aaron Digulla

@AaronDigulla Tôi không thấy lý do tại sao bạn nghĩ rằng một mô hình như trang trí là một triển khai nặng như vậy; bạn đang nói về một vài dòng mã. Một lớp chứa một lớp khác và chuyển tiếp yêu cầu đến nó với một số chức năng được thêm vào. Nó sử dụng sự kế thừa và thành phần theo cách làm cho việc gọi một đối tượng được trang trí tương đương với việc gọi chính đối tượng đó. Tôi coi sự minh bạch này là một thế mạnh. Điều này cho phép bạn trao đổi trang trí trong thời gian chạy. Khi bạn nói rằng Groovy không cần trang trí bởi vì nó có thể thêm các phương thức vào một lớp, có vẻ như bạn đang thiếu điểm.

— Despertar

2

Mẫu Iterator chưa được thay thế bởi bất kỳ tính năng ngôn ngữ mới nào trong các ngôn ngữ hiện đại. Nó chỉ đi kèm với một triển khai mặc định cho các bộ sưu tập phổ biến. Chỉ vì nó có cài đặt mặc định không có nghĩa là mẫu không được sử dụng. Nếu bạn viết bộ sưu tập của riêng bạn, bạn sẽ phải tự thực hiện nó.

— Despertar

10

LtU đề cập rằng Jeremy Gibbons đang viết một cuốn sách về các mẫu trong lập trình chức năng. Kiểm tra các mẫu của ông Gibbon trong blog Lập trình chức năng để biết một vài lời trêu ghẹo. Lưu ý anh ấy khuyên bạn nên đọc bài viết của mình từ cũ nhất đến mới nhất.

Các mẫu thiết kế giấy của ông dưới dạng các chương trình kiểu dữ liệu chung (pdf) theo thứ tự cao hơn mô hình hóa một cách chức năng mô hình Gang of Four: Hợp chất, Trình lặp, Trình truy cập và Trình tạo. Ông mô tả các mô hình lập trình với các phương trình đệ quy trong Lập trình Origami (nếp gấp và mở ra).

— Tháng ba
nguồn

9

Có các mẫu thiết kế SQL .

Và một số mẫu thiết kế chức năng tồn tại là tốt - xem ở đây cho scala.

— Oded
nguồn

Liên kết scala bị hỏng

— corvus_192

7

Thay vì đặt tên cho các mẫu thiết kế không phải là oo, tôi muốn cung cấp cho bạn một vài ví dụ về các cuốn sách có nhiều mẫu thiết kế (trong đó một số mẫu vẫn sẽ là OO cụ thể):

Nhìn vào Sách POSA để biết ví dụ về kiến trúc phần mềm
- Phân phối máy tính
- Các mẫu cho các đối tượng đồng thời và nối mạng
- Các mẫu cho quản lý tài nguyên
Fowlers mô hình kiến trúc doanh nghiệp với danh mục trực tuyến
Các mẫu thử nghiệm xUnit với trang web
Và tất nhiên, nơi các mô hình bắt nguồn: cách xây dựng vượt thời gian của Christopher Alexandeller

Hi vọng điêu nay co ich

— KeesDijk
nguồn

Đây cũng là những mô hình tôi muốn giới thiệu, cộng với Mô hình tích hợp doanh nghiệp của Hohpe & Woolf .

— TMN

Các mẫu của Fowler rất OO :)

— David Conde

@David Conde :) Hầu hết trong số chúng là OO thuần túy, Tất cả chúng đều được viết theo cách OO, nhưng một số trong số chúng cũng áp dụng cho không OO: xem "Mẫu trình bày web", "Mẫu trạng thái phiên", "Mẫu phân phối "

— KeesDijk

2

Trong lập trình chức năng (đặc biệt là Haskell), có rất nhiều mẫu và thành ngữ không ánh xạ rất tốt đến OOP. Các loại Phantom là một ví dụ nổi tiếng và bạn có thể tìm thấy nhiều hơn trên trang wiki haskell trên Thành ngữ .

— yatima2975
nguồn

1

Lập trình mô-đun khá phổ biến đối với các thư viện số và các ứng dụng nặng về toán học (phần mềm số nổi tiếng là khó mô hình hóa bằng cách sử dụng các mẫu Hướng đối tượng, chủ yếu là do có rất ít bạn có thể gói gọn).

— quant_dev
nguồn

Được sử dụng trong JS & "thuần C": en.wikipedia.org/wiki/Module_potype

— umlcat

1

Một ví dụ điển hình về các mẫu không OOP là danh mục mẫu yêu thích tuyệt đối của tôi: Các mẫu tổ chức phát triển phần mềm linh hoạt, của James O. Coplien . Cuốn sách này không phải là về các mẫu phần mềm, nói về con người, một danh mục để tạo ra các nhóm thành công. Mỗi người quản lý nên đọc cuốn sách này!

— JuanZe
nguồn

0

Tôi thích nghĩ về các cấu trúc dữ liệu như Hàng đợi, Danh sách được liên kết, Cây, biểu đồ, v.v. như các mẫu. Họ xác định các mẫu nhất định để lưu trữ dữ liệu và xử lý chúng. Chúng có vẻ nguyên thủy so với các patters cao cấp hơn của Gang of Four nhưng chúng vẫn là những mẫu. Ý tôi là, điều gì sẽ xảy ra nếu ai đó thực hiện một ngăn xếp như là một FIFO thay vì LIFO và ngược lại cho một hàng đợi và đặt tên cho chúng theo cách khác?

— Sở DPD
nguồn