Có phải Gang of Four đã khám phá kỹ lưỡng về mô hình không gian mô hình không?

144

Kể từ lần đầu tiên tôi biết về các mẫu thiết kế của Gang of Four (GoF) , ít nhất 10 năm trước, tôi có cảm tưởng rằng 23 mẫu này chỉ là một mẫu nhỏ của một thứ gì đó lớn hơn nhiều mà tôi muốn gọi là Không gian mẫu . Không gian mẫu giả định này bao gồm tất cả các giải pháp được đề xuất (đã biết hoặc chưa biết) cho các vấn đề thiết kế phần mềm hướng đối tượng phổ biến.

Vì vậy, tôi hy vọng số lượng các mẫu thiết kế đã biết và được ghi nhận sẽ tăng lên đáng kể.

Nó đã không xảy ra. Hơn 20 năm sau khi cuốn sách GoF ra mắt, chỉ có 12 mẫu bổ sung được liệt kê trong bài viết Wikipedia, hầu hết chúng ít phổ biến hơn nhiều so với bản gốc. (Tôi không bao gồm các mẫu đồng thời ở đây vì chúng bao gồm một chủ đề cụ thể.)

Những lý do là gì?

Tập hợp các mẫu của GoF có thực sự toàn diện hơn tôi nghĩ không?
Có phải sự quan tâm trong việc tìm kiếm các mẫu mới giảm xuống, có thể bởi vì chúng đã được tìm thấy không hữu ích lắm trong thiết kế phần mềm?
Thứ gì khác?

design-patterns object-oriented-design

— Frank Puffer
nguồn

49

Các mẫu có ở khắp mọi nơi nhưng chúng thường được sử dụng theo cách vô vị và robot. Vì lý do đó, tôi nghĩ rằng, ý tưởng danh mục mẫu trở nên ít phổ biến hơn.

— usr

6

Không gian thiết kế? Ai đó có được Mark Rosewater ở đây, stat!

— corsiKa

16

Martin Fowler đã xuất bản Các mẫu Kiến trúc ứng dụng doanh nghiệp năm 2003 ghi lại khoảng 50 mẫu, nhiều mẫu vẫn còn khá dễ sử dụng và được sử dụng tốt hiện nay, ví dụ: "Data Mapper", "Plugin", "Lazy Load", "Lớp dịch vụ", v.v.

— Brian Rogers

2

Khám phá không gian của tất cả các mẫu có thể sẽ giống như không khám phá không gian của các mẫu có thể. Bạn có thể làm cho mọi thứ một mô hình. Nếu bạn biến mọi thứ thành một mô hình thì không có gì là một mô hình, vì từ đó mất đi ý nghĩa của nó.

— Hy vọng có ích vào

4

@BradThomas: Chắc chắn, giống như với hầu hết các câu hỏi thú vị, mọi người có xu hướng có một ý kiến nhất định. Nhưng ý kiến ít nhất một phần dựa trên sự thật, và tôi đã tìm thấy nhiều sự thật xen kẽ trong câu trả lời cho câu hỏi này sẽ giúp bản thân tôi và hy vọng những người khác nghĩ lại ý kiến của họ và đưa ra những ý kiến rõ ràng hơn.

— Frank Puffer

165

Khi cuốn sách ra mắt, rất nhiều người đã nghĩ như vậy và có nhiều nỗ lực để tạo ra "thư viện mẫu" hoặc thậm chí là "cộng đồng mẫu". Bạn vẫn có thể tìm thấy một số trong số họ:

"Cộng đồng mẫu" , WikiWikiWeb
"Nhóm nghiên cứu các mẫu thiết kế của thành phố New York" , Logic công nghiệp
"Danh mục mẫu" , Nhóm Hillside

Nhưng sau đó...

Có phải sự quan tâm trong việc tìm kiếm các mẫu mới giảm xuống, có thể bởi vì chúng không thực sự hữu ích trong thiết kế phần mềm?

Điều này, rất nhiều. Quan điểm của các mẫu thiết kế là cải thiện giao tiếp giữa các nhà phát triển, nhưng nếu bạn cố gắng thêm nhiều mẫu hơn, bạn sẽ nhanh chóng đến điểm mà mọi người không thể nhớ chúng, hoặc đánh giá sai chúng, hoặc không đồng ý về chính xác chúng sẽ trông như thế nào và giao tiếp là gì trong thực tế, không được cải thiện Điều đó đã xảy ra rất nhiều với các mẫu GoF.

Cá nhân, tôi còn đi xa hơn: Thiết kế phần mềm, đặc biệt là thiết kế phần mềm tốt, quá khác biệt để được nắm bắt một cách có ý nghĩa trong các mẫu, đặc biệt là trong số ít mẫu mà mọi người thực sự có thể nhớ - và chúng quá trừu tượng đối với mọi người thực sự nhớ nhiều hơn một chút Vì vậy, họ không giúp đỡ nhiều.

Và có quá nhiều người trở nên say mê với khái niệm này và cố gắng áp dụng các mẫu ở khắp mọi nơi - thông thường, trong mã kết quả, bạn không thể tìm thấy thiết kế thực tế giữa tất cả các Singletons (hoàn toàn vô nghĩa) và các nhà máy trừu tượng.

— Michael Borgwardt
nguồn

50

Ý kiến gây tranh cãi: Nhà máy trừu tượng dù sao cũng là một mùi mã :)

— MetaFight

66

Ý kiến gây tranh cãi, có thể, nhưng một ý kiến rất quan trọng để thể hiện. Các mẫu thiết kế có nguy cơ trở thành một ví dụ về quần áo mới của hoàng đế, nơi tất cả chúng ta đều sợ hãi khi đặt câu hỏi liệu chúng có hữu ích không. Làm tốt.

— David Arno

18

@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();

— corsiKa

11

" Quan điểm của các mẫu thiết kế là cải thiện giao tiếp giữa các nhà phát triển " Tôi nghĩ rằng các mẫu thiết kế là để giải quyết các vấn đề thường gặp (và khá thường xuyên độc lập) mà các nhà phát triển gặp phải. Các tiêu chuẩn cải thiện giao tiếp và do sự biến động (các mẫu phát sinh từ các vấn đề XY, các mẫu được coi là chống mẫu), nhiều người không coi các mẫu thiết kế là tiêu chuẩn. Các mẫu thiết kế rất tốt trong việc thiếu các tính năng ngôn ngữ và tôi tin rằng các nhà thiết kế ngôn ngữ đang thực hiện các sửa lỗi này trước khi chúng trở thành các mẫu thiết kế. Mặc dù vậy, đừng tin lời tôi

— Vince Emigh

11

@ChrisW Tôi không thấy quan điểm của bạn ... Như tôi đã nói, GoF đã cố gắng khắc phục những thiếu sót của OO, và đặc biệt là những thiếu sót của C ++ 98 vì đây là ngôn ngữ được họ lựa chọn cùng với Smalltalk. Họ thực sự đã viết: "Sự lựa chọn ngôn ngữ lập trình rất quan trọng vì nó ảnh hưởng đến quan điểm của một người. Các mẫu của chúng tôi giả sử các tính năng ngôn ngữ cấp độ Smalltalk / C ++ và lựa chọn đó xác định những gì có thể và không thể thực hiện dễ dàng."

— Shautieh

108

Tôi có ấn tượng rằng 23 mẫu này chỉ nên là một mẫu nhỏ của một cái gì đó lớn hơn nhiều mà tôi muốn gọi là Không gian mẫu.

Đây là giả định khủng khiếp được truyền bá bởi các lập trình viên tân sinh ở khắp mọi nơi, các lập trình viên nghĩ rằng họ có thể viết một chương trình chỉ bằng cách ghép các mẫu phần mềm lại với nhau. Nó không hoạt động theo cách đó. Nếu có một "không gian mẫu" như vậy, bạn có thể cho rằng kích thước của nó là vô hạn.

Các mẫu thiết kế (theo nghĩa của GoF) có một mục đích: để bù đắp cho sự thiếu hụt trong ngôn ngữ lập trình bạn đang sử dụng.

Các mẫu thiết kế không phải là phổ quát cũng như toàn diện. Nếu bạn thay đổi sang một ngôn ngữ lập trình khác, biểu cảm hơn, hầu hết các mẫu trong sách GoF đều trở nên không cần thiết và không mong muốn.

— Robert Harvey
nguồn

40

"Các mẫu thiết kế (theo nghĩa của GoF) có một mục đích: để bù đắp cho sự thiếu hụt trong ngôn ngữ lập trình bạn đang sử dụng." Tôi tiếp tục nghe điều này, nhưng vẫn chưa thấy nó hợp lý. Mọi biện minh được cho là của nó chỉ chỉ ra một số mẫu dễ thực hiện hơn trong các ngôn ngữ với một số tính năng - thường là Người truy cập và có lẽ là Singleton - và khiến phần lớn các mẫu không bị ảnh hưởng, chỉ ngụ ý rằng chúng cũng có thể được dự phòng ngôn ngữ tốt hơn. Nhưng làm thế nào để chúng ta biết? Tính năng ngôn ngữ nào làm cho Observer không liên quan? Chuỗi trách nhiệm? Hợp chất?

— Jules

56

@Jules Các hàm hạng nhất một mình loại bỏ một khối lớn của chúng, bao gồm Chuỗi trách nhiệm (nó chỉ là thành phần của một danh sách các hàm). Lập trình phản ứng chức năng loại bỏ mẫu Observer. Mẫu tổng hợp chỉ là một định nghĩa ít được chỉ định chặt chẽ hơn về các đơn sắc, và các ngôn ngữ với các kiểu chữ và tập trung vào các luật đại số cung cấp các công cụ mạnh mẽ để làm việc với các đơn sắc. Tôi có thể liệt kê nhiều hơn nhưng bạn có ý tưởng.

— Jack

12

@Jules: Tôi tin rằng cuốn sách GoF ban đầu liệt kê iterator là một mẫu, nhưng bây giờ việc chuyển đổi thành tính năng ngôn ngữ về cơ bản đã hoàn tất trong mọi ngôn ngữ OOP từ xa.

— Kevin

9

@RubberDuck làm thế nào để mẫu đã được triển khai làm cho mẫu bị lỗi thời? Đó vẫn là mẫu thiết kế đang được thực hiện. Các bộ tính năng ngôn ngữ khác nhau có thể dẫn đến việc triển khai mẫu khác nhau, nhưng bản thân mẫu vẫn ở đó. Các mẫu có sẵn để dễ dàng giao tiếp bằng cách đặt tên cho các chiến lược định kỳ được sử dụng phổ biến. Trong trường hợp, các lớp .NET được gọi ObservableSomething<T>để dễ hiểu mục đích của chúng, bởi vì nó sử dụng tên mẫu thường được biết đến. Một mô hình là một ý tưởng, không phải là một thực hiện chính xác.

— null

29

@Jules: Chương trình là gì? Một giải pháp cho một vấn đề tái diễn. Mẫu thiết kế là gì? Một giải pháp cho một vấn đề tái diễn. Tại sao nó không phải là một chương trình? Bởi vì chúng tôi không thể diễn đạt nó như một chương trình. Ergo, Mẫu thiết kế là một giải pháp cho vấn đề tái diễn mà đúng hơn là Chương trình, không phải là Mẫu thiết kế, nhưng không thể là Chương trình, vì ngôn ngữ không đủ biểu cảm để diễn đạt Chương trình. Ví dụ: cách đây không lâu, "Cuộc gọi chương trình con" là một mẫu thiết kế! Ngày nay, nó là một tính năng ngôn ngữ.

— Jörg W Mittag

61

Tôi nghĩ rằng có ba yếu tố đi vào chơi ở đây.

Thiếu khối lượng quan trọng

Đầu tiên, một mẫu về cơ bản ít hơn là đặt tên cho một số mã thực hiện một "khối" chức năng cụ thể. Cách duy nhất mà tên cung cấp nhiều giá trị thực là nếu bạn có thể phụ thuộc vào mọi người biết tên đó có nghĩa là gì, chỉ bằng cách sử dụng tên, họ ngay lập tức hiểu khá nhiều về mã.

Các mô hình không bao giờ thiết lập khối lượng quan trọng mà họ cần để thực hiện điều đó mặc dù. Thay vào đó là ngược lại, AAMOF. Trong 20 năm hoặc lâu hơn kể từ khi cuốn sách GoF ra mắt, tôi khá chắc chắn rằng tôi đã thấy hàng tá cuộc trò chuyện trong đó mọi người tham gia thực sự biết đủ các mẫu thiết kế để họ sử dụng để cải thiện giao tiếp.

Nói một cách dễ hiểu hơn: các mẫu thiết kế thất bại đặc biệt vì chúng thất bại.

Quá nhiều mẫu

Tôi nghĩ yếu tố chính thứ hai là, nếu có bất cứ điều gì, ban đầu họ đặt tên quá nhiều mẫu. Trong một số lượng lớn các trường hợp, sự khác biệt giữa các mẫu đủ tinh tế đến mức không thể nói chắc chắn thực sự liệu một lớp cụ thể có phù hợp với mẫu này hay mẫu khác (hoặc có thể cả hai - hoặc có thể không).

Mục đích là bạn có thể nói về mã ở mức cao hơn. Bạn có thể gắn nhãn một đoạn mã khá lớn là việc triển khai một mẫu cụ thể. Đơn giản bằng cách sử dụng tên được xác định trước đó, mọi người nghe thường sẽ biết nhiều như họ quan tâm đến mã đó, vì vậy bạn có thể chuyển sang điều tiếp theo.

Thực tế có xu hướng gần như ngược lại. Giả sử bạn đang họp và nói với họ rằng lớp đặc biệt này là Mặt tiền. Một nửa số người trong cuộc họp hoặc không bao giờ biết hoặc từ lâu đã quên chính xác điều đó có nghĩa là gì. Một trong số họ yêu cầu bạn nhắc nhở anh ta về (các) sự khác biệt chính xác giữa một Mặt tiền và, giả sử, một Proxy. Ồ, và một vài người thực sự biết mô hình dành phần còn lại của cuộc họp để tranh luận liệu điều này thực sự nên được coi là Mặt tiền hay "chỉ" một Bộ chuyển đổi (với một anh chàng vẫn khăng khăng rằng nó có vẻ giống như một Proxy đối với anh ta).

Cho rằng ý định của bạn thực sự chỉ là để nói: "mã này không thú vị lắm, hãy tiếp tục", cố gắng sử dụng tên của một mẫu chỉ thêm sự phân tâm, không phải giá trị.

Thiếu sự quan tâm

Hầu hết các mẫu thiết kế không thực sự xử lý các phần thú vị của mã. Họ đối phó với những thứ như: "làm thế nào để tôi tạo ra những vật thể này?" Và "làm thế nào để tôi có thể nói chuyện với đối tượng đó?" Ghi nhớ tên mẫu cho những cái này (cũng như các đối số đã nói ở trên về các chi tiết và như vậy) chỉ đơn giản là đặt nhiều năng lượng vào những thứ mà hầu hết các lập trình viên không quan tâm lắm.

Nói cách khác một chút: các mẫu xử lý những thứ giống nhau giữa nhiều chương trình - nhưng điều thực sự làm cho chương trình trở nên thú vị là nó khác với các chương trình khác như thế nào .

Tóm lược

Các mẫu thiết kế thất bại vì:

Họ đã không đạt được khối lượng quan trọng.
Sự khác biệt giữa các mẫu là không đủ để đảm bảo sự rõ ràng.
Họ chủ yếu xử lý các phần của mã hầu như không ai thực sự quan tâm.

— Quan tài Jerry
nguồn

2

"... nhưng điều thực sự làm cho chương trình trở nên thú vị là nó khác với các chương trình khác như thế nào." Tôi hoàn toàn đồng ý nhưng trước tiên bạn phải có cùng một phần, có thể chúng chỉ khác nhau bởi một khía cạnh tầm thường nào đó. Nếu bạn thư giãn một chút, cần phải đặt tên và xác định các mẫu tôi tin chắc là người ta sẽ thấy các mẫu gần như mọi lúc. Chỉ là họ gần như không bao giờ ở dạng thuần túy mà luôn luôn ít nhiều thích nghi với vấn đề trong tay.

— Trilarion

5

Câu trả lời rất hay.

— Robert Harvey

4

@Trilarion: Ồ, tôi nhận ra những phần của mã phải được viết. Chúng giống như những chiếc lốp trên xe của bạn. Bạn rất cần lốp xe để lái xe - nhưng hầu hết mọi người vẫn hầu như không biết thương hiệu lốp xe trên xe của họ. Đây là yêu cầu họ học thuật ngữ đặc biệt cho một lốp xe với các đường chéo không đối xứng. Ai biết được - những người đó có thể đã cứu mạng tôi một lần, nhưng tôi vẫn không dành cả đời để học tên cho họ.

— Jerry Coffin

3

@DavidR Richby: Được rồi, sau đó hãy sử dụng phiên bản "phía nhà sản xuất" của sự tương tự. Có vấn đề gì không khi John thiết kế lốp cho Goodyear sử dụng một từ cho loại rãnh đó, nhưng Pierre, người làm việc cho Michelin lại sử dụng một từ hoàn toàn khác? Có vấn đề gì khi người ta chỉ sử dụng một từ chỉ về rãnh, nhưng từ còn lại chỉ một lốp xe hoàn chỉnh với các rãnh ngang ở một bên của trung tâm và các rãnh chéo ở bên kia?

— Jerry Coffin

2

@immibis: Tôi sẽ nói chủ yếu là có, họ đã thất bại. Tôi muốn nói có ít hơn một nửa tá mẫu mà hầu hết các lập trình viên nhận ra. Singleton nổi tiếng, nhưng thực sự chỉ hiếm khi áp dụng (tốt nhất). Cái tên "Nhà máy" đã được sử dụng phổ biến từ lâu trước khi "mẫu" đến cùng (Tôi nhớ việc sử dụng nó vào cuối năm 1970 hoặc rất đầu những năm 1980). Các mô hình được cho là tạo thành một từ vựng, nhưng hiện tại chúng giống như từ vựng của tôi trong tiếng Hy Lạp - đủ để (có thể) khiến tôi gặp rắc rối, nhưng chắc chắn không đủ để ra khỏi thực đơn, ít hơn một cuộc trò chuyện có ý nghĩa.

— Jerry Coffin

35

Các mẫu bị thiếu trừu tượng, các mẫu đơn giản được trừu tượng hóa, các mẫu phức tạp không được nhận dạng, do đó các mẫu không hữu ích (ngoại trừ một số mẫu cấp cao).

Tôi nghĩ Paul Graham đã nói điều đó tốt nhất:

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 một chương trình chỉ phản ánh 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 bằng tay các bản mở rộng của một số macro mà tôi cần viết.

Khi bạn nhận ra một mẫu trong mã của mình, điều đó có nghĩa là một cái gì đó lặp lại và bạn nên sử dụng một sự trừu tượng hóa tốt hơn. Nếu bạn không có sự trừu tượng hóa tốt hơn, bạn sử dụng mô hình như một cách giải quyết. Bởi vì các ngôn ngữ lập trình mới hơn cung cấp sự trừu tượng tốt hơn, các mẫu trở nên ít hữu ích hơn nhiều.
Ngoài ra các mẫu đơn giản thường dễ dàng trừu tượng hóa và các mẫu phức tạp hiếm khi được nhận ra.
Khi một mẫu bị thay thế bởi một sự trừu tượng, điều đó không có nghĩa là khái niệm đằng sau mẫu đó biến mất, nhưng khái niệm này có thể được viết rõ ràng thay vì gián tiếp và nó không còn đặc biệt so với mã khác và nó không còn được nhận ra là một mô hình.

— Siphor
nguồn

2

Cá nhân, tôi bằng cách nào đó thực sự thích ý tưởng này. Nhưng sau đó, mã nên được đọc bởi con người và mọi người như các mẫu. Các mẫu giúp chúng tôi tìm đường xung quanh. Xóa tất cả các mẫu khỏi mã của chúng tôi sẽ làm cho nó không thể đọc được.

— Frank Puffer

2

@Frank Tôi nghĩ rằng PG đến từ đâu là một mô hình là "mùi" của một chức năng cơ bản mà bạn có thể trừu tượng hóa, và thực tế là bạn đã không kéo nó ra thành một chức năng hoặc macro là nguyên nhân gây ra sự lặp lại - như nếu bạn không có String.replacechức năng, bạn có thể tưởng tượng nó bật lên như một mẫu, nhưng tốt hơn là viết nó một lần thay vì tiếp tục thực hiện lại nó. Đồng ý rằng nếu bạn không đặt tên cho những thứ này một cách chính xác thì nó sẽ khiến bạn khó đọc hơn, nhưng khi nó được thực hiện đúng, mã sẽ đọc IMO khai báo nhiều hơn (ví dụ: getOrElsekiểu của các đơn vị tùy chọn so với kiểm tra null)

— otherdave

11

Trích dẫn của Paul Graham là về việc giữ các giải pháp của bạn DRY, khác với ý tưởng "mẫu" của GoF. Ý tưởng của GoF là về việc đặt tên cho các giải pháp thường được sử dụng. Chúng tôi đã làm điều đó rất lâu trước khi GoF xuất bản cuốn sách của họ. Ví dụ, tôi có thể nói với đồng nghiệp của mình rằng tôi sẽ sử dụng hàng đợi và đồng nghiệp của tôi ngay lập tức biết tôi đang nói về điều gì mà không cần phải giải thích chi tiết về việc hàng đợi làm gì hoặc cách thức hoạt động của nó. Nhưng, xem câu trả lời tuyệt vời của Michael Borgwardt, ở trên.

— Solomon chậm

10

Theo tôi, câu trả lời này hiểu sai về mô hình là gì. Một mẫu thiết kế là một giải pháp thường gặp phải cho một vấn đề phổ biến. Nó không phải là một số sao chép mã. Nói, lấy một vòng lặp. Bạn giải quyết vấn đề trừu tượng hóa container để bạn có thể đi qua các phần tử bên trong nó bất kể container là gì. Do đó, bạn tạo một lớp lặp để thực hiện điều đó cho mỗi vùng chứa của bạn và làm cho chúng thực hiện một giao diện chung. Tóm tắt gì ở đây? Một iterator đã là một sự trừu tượng. Và, tất nhiên, nó được triển khai khác nhau cho tất cả các container, do đó không sao chép mã.

— Malcolm

3

Phần chính trong trích dẫn của Graham thường là tôi đang tạo ra bằng tay các bản mở rộng của một số macro mà tôi cần viết. Điều này tham khảo các macro Lisp cụ thể. Chỉ có rất nhiều sự trừu tượng mà người ta có thể làm mà không cần macro.

— Bart van Nierop

13

Mặc dù tôi hầu hết đồng ý với những gì người khác trả lời ở đây, cá nhân tôi nghĩ rằng một lý do chính cho số lượng mẫu không tăng là các mẫu bị mất ý nghĩa khi có vô số mẫu. Điều tuyệt vời với vài mẫu này là, chúng bao gồm rất nhiều miền vấn đề theo một cách tiêu chuẩn. Nếu bạn tập trung vào một miền mẫu vô tận, bạn sẽ không có mẫu nào cả. Nó hơi giống như "đường bờ biển của một hòn đảo dài bao nhiêu?". Nếu bạn đo trên bản đồ, bạn đi kèm với một con số kha khá. Nhưng nếu bạn cố gắng để có được độ chính xác cao hơn và đạt được độ phân giải tốt hơn, bạn sẽ thấy rằng độ dài ngày càng tăng lên đến vô cùng (hoặc không chắc chắn; bạn sẽ đo đường viền chính xác bằng thủy triều và ở mức độ nguyên tử như thế nào?).

— qwerty_so
nguồn

1

Đúng, các mẫu chỉ có thể hoạt động nếu không có quá nhiều. Nhưng tại sao những người GoF vẫn là những người phổ biến nhất? Một số trong số chúng hiện được coi là antipotype của nhiều người (Singleton, Builder, v.v.). Điều này sẽ tạo chỗ cho các mẫu mới, hữu ích hơn mà không tăng tổng số.

— Frank Puffer

2

Tôi đoán nó giống như 10 điều răn. Nguồn chỉ còn 2 ký tự (GOF, GOE, GOD) xD

— qwerty_so

9

Vâng, và đôi khi có vẻ như công nghệ phần mềm hiện đại liên quan đến GoF giống như các học giả thời trung cổ liên quan đến Aristotle.

— Frank Puffer

11

Một cái gì đó mà không có câu trả lời nào khác đề cập đến cũng có liên quan:

Sự gia tăng của các ngôn ngữ gõ động.

Khi cuốn sách lần đầu tiên xuất hiện, đã có cuộc thảo luận nghiêm túc rằng Java chỉ quá chậm để thực hiện công việc thực sự. Bây giờ Java thường được sử dụng trên các ngôn ngữ biểu cảm hơn vì tốc độ của nó. Có thể Ruby, Python, JavaScript, et al vẫn còn quá chậm đối với một số lớp ứng dụng quan trọng, nhưng nói chung, chúng đủ nhanh cho hầu hết các mục đích. Và ít nhất JavaScript thực sự trở nên nhanh hơn mặc dù có nhiều tính năng được đóng gói trong mỗi bản phát hành.

Cuốn sách GoF ban đầu có các mẫu trong cả smalltalk và c ++, và nếu bộ nhớ phục vụ thì các mẫu luôn luôn ngắn hơn trong smalltalk và đôi khi đáng kể là như vậy. Một số tính năng của các mẫu thiết kế cổ điển thực sự là cách để thêm các tính năng động vào hệ thống được nhập tĩnh (như Tóm tắt đã được thảo luận, trong đó bạn khởi tạo lớp chính xác dựa trên dữ liệu thời gian chạy). Những người khác thì ngắn hơn rất nhiều trong các ngôn ngữ động mà họ chỉ đơn giản là sử dụng thành ngữ của chính ngôn ngữ đó.

— Jared Smith
nguồn

10

Nó đã xảy ra. Hàng chục nếu không phải hàng trăm cuốn sách được xuất bản giống như một nỗ lực nhằm giảm toàn bộ khoa học máy tính để thiết kế các mẫu, vì các nhà xuất bản và tác giả đã cố gắng nhảy vào (hoặc tạo ra) một bandwagon khác. Tôi có một kệ của họ. Chưa bao giờ được hỏi ý kiến kể từ lần quét đầu tiên, và vâng tôi là một kẻ hút máu, bởi vì có rất ít hoặc không có gì trong sử dụng thực tế hoặc chưa được biết đến nhiều (ví dụ như Type Object, không có gì khác hơn hình thức bình thường thứ ba được thể hiện qua một tá trang thay vì một đoạn văn), và vì rõ ràng càng ít mẫu thì càng tốt: một điểm đã lảng tránh hầu hết các nhà thực hành. Thật vậy, khi tôi đăng một phản bác của Type Object, tôi được hướng dẫn lấy lại văn bản của mình dưới dạng mẫu thiết kế.Câu chuyện có thật. Điều này cũng cho thấy một thiếu sót khác của dự án: không có cơ chế xem xét hoặc loại trừ hoặc từ chối.

Vì thực tế, GoF đã không thực sự cố gắng 'tìm hiểu kỹ các mẫu thiết kế'. Thay vào đó, họ đã tham gia vào một dự án lớn hơn nhiều: giới thiệu 'ngôn ngữ mẫu' vào CS, với tất cả các arcana, Người tham gia, v.v.

Những gì họ đã làm được, rất hữu ích, là hai điều:

xuất bản một số thủ thuật hữu ích như mẫu Khách truy cập
cung cấp một bộ tên tiêu chuẩn bị mắc kẹt phần lớn: Factory, Adaptor, Iterator, ... Nếu bạn nhìn vào CORBA, được thiết kế ngay trước đó, bạn sẽ thấy giá trị của điều này: tất cả các loại tên 'nước ngoài' như Interceptor , Người giúp việc, Người môi giới, ...

Một khái niệm hữu ích khác nảy sinh là 'chống mẫu', ví dụ 'đăng nhập và ném'. Dự án, giống như nhiều mốt nhất thời trong CS, đã bị trật tự bởi truyền giáo của chính nó và bị chấp nhận một cách sai lầm như một tôn giáo CS khác, và nó đã đi theo cách của hầu hết các tôn giáo như vậy: hữu ích trong các phần, nhưng chắc chắn là 'không có viên đạn bạc' (c ) Fred Brooks, 1965). Đáng buồn là chúng ta phải tiếp tục khám phá lại rằng cứ sau vài năm thực sự.

— người dùng207421
nguồn

Có còn buồn không nếu nó dẫn đến cuộc thảo luận này (và tất cả những gì đòi hỏi)

— r3wt

1

@ r3wt Không sequitur. Điều tôi nói là đáng buồn là sự yếu kém của ngành công nghiệp CNTT khi nghĩ rằng mọi sự phát triển mới sẽ là viên đạn bạc huyền thoại và tình cờ làm hỏng một số công việc trước đó của chính nó.

— dùng207421

2

nhìn nó từ một khía cạnh khác Tôi không buồn khi đọc câu trả lời của bạn, học cách không lặp lại sai lầm. Vì vậy, những gì bạn cho là thực sự rất hữu ích cho người khác.

— r3wt

6

Có / một số cuốn sách có tiêu đề PLoP ( Ngôn ngữ mẫu của thiết kế chương trình ), mỗi cuốn là một tuyển tập các bài báo được trình bày tại một hội nghị hàng năm .

Đọc sách, tôi thấy một số mô hình rất thú vị và mới đối với tôi, một số trong số chúng là các tiêu chuẩn (ví dụ: "một nửa đối tượng cộng với giao thức").

Vì vậy, không, bộ sưu tập của GoF không đầy đủ và truyền cảm hứng / truyền cảm hứng cho mọi người để thu thập / mô tả / khám phá / phát minh ra những cái mới.

"Chỉ có 12 mẫu bổ sung được liệt kê trong bài viết Wikipedia" có lẽ cũng không phải là một bộ sưu tập hoàn chỉnh: tức là có những mẫu khác được ghi lại ở nơi khác, ví dụ như trong sách PLoP và có thể ở những nơi khác.

— Chris
nguồn

Có, bạn có thể tìm thấy mô tả của hàng trăm mẫu nếu bạn tìm kiếm chúng. Nhưng không ai trong số này dường như gần như phổ biến như những người GoF.

— Frank Puffer

Đó là bởi vì tôi thích đọc cuốn sách GoF mà tôi đã đọc nhiều hơn (những cuốn sách) khi chúng được xuất bản (sau này).

— ChrisW

1

@FrankPuffer Tôi cá là các mẫu rất phổ biến, ngay cả khi tên không có.

— dcorking

5

Cuốn sách Gang of Four (GoF) chứa hầu hết các mẫu mà một lập trình viên có kinh nghiệm trong một ngôn ngữ không có chức năng nào có trong vành đai công cụ của họ. Nó giống như bộ công cụ cơ bản mà tất cả các nhà xây dựng đều biết cách sử dụng. Đóng góp chính của cuốn sách là đặt tên được xác định rõ ràng cho các mẫu được sử dụng phổ biến bởi hầu hết các lập trình viên có kinh nghiệm tại thời điểm đó và do đó hỗ trợ giao tiếp giữa các lập trình viên thảo luận về các tùy chọn thiết kế.

Bạn hy vọng rằng một thợ điện có một số công cụ mà một người xây dựng bình thường không có, tương tự như vậy, bạn sẽ mong rằng một lập trình viên WPF biết các mẫu thiết kế cho các thuộc tính phụ thuộc của Nether, hoặc một Lập trình viên SQL SQL để biết mẫu thiết kế để sử dụng các trình kích hoạt tạo dữ liệu kiểm toán.

Tuy nhiên, chúng tôi không nghĩ đây là những mẫu Thiết kế của nhóm vì chúng chỉ được sử dụng với một công nghệ.

Một số thiết kế modem nhiều sách mẫu là “Refactoring, Cải thiện thiết kế của hiện tại Mã (Martin Fowler)” và “Mã sạch: Một cuốn sổ tay của Agile Software Nghề thủ công (Robert C. Martin) ” Cả hai cuốn sách trình bày các nội dung như biến đổi bạn thực hiện đối với mã hiện tại của bạn, chứ không phải là thiết kế có thể tái sử dụng trước của Cameron, tuy nhiên chúng cũng giống như các mẫu thiết kế của Cameron.

— Ian
nguồn

3

Đây là một cuộc phỏng vấn với Erich Gamma nơi anh ấy suy nghĩ về lựa chọn mẫu của họ và những gì họ sẽ thay đổi ngày hôm nay (cũng như ngày nay 10 năm trước, haha).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Làm thế nào bạn sẽ cấu trúc lại "Mẫu thiết kế"?

Erich: Chúng tôi đã thực hiện bài tập này vào năm 2005. Dưới đây là một số lưu ý từ phiên của chúng tôi. Chúng tôi đã thấy rằng các nguyên tắc thiết kế hướng đối tượng và hầu hết các mẫu không thay đổi kể từ đó. Chúng tôi muốn thay đổi phân loại, thêm một số thành viên mới và cũng bỏ một số mẫu. Hầu hết các cuộc thảo luận là về việc thay đổi phân loại và đặc biệt là loại bỏ.

Khi thảo luận về những mẫu sẽ bỏ, chúng tôi thấy rằng chúng tôi vẫn yêu tất cả chúng. (Không thực sự là tôi ủng hộ việc bỏ Singleton. Công dụng của nó hầu như luôn luôn là mùi thiết kế.)

Vì vậy, đây là một số thay đổi:

Thông dịch viên và Flykg nên được chuyển sang một danh mục riêng mà chúng tôi gọi là "Khác / Hợp chất" vì chúng thực sự là những quái thú khác với các mẫu khác. Phương pháp nhà máy sẽ được khái quát cho Nhà máy.

Các danh mục là: Lõi, Sáng tạo, Ngoại vi và Khác. Mục đích ở đây là nhấn mạnh các mẫu quan trọng và tách chúng ra khỏi các mẫu ít được sử dụng.

Các thành viên mới là: Đối tượng Null, Đối tượng loại, Tiêm phụ thuộc và Đối tượng / Giao diện mở rộng (xem "Đối tượng mở rộng" trong Ngôn ngữ mẫu của Thiết kế chương trình 3, Addison- Wesley, 1997).

Đây là các loại:

Core: Hợp chất, Chiến lược, Trạng thái, Lệnh, Lặp, Proxy, Phương thức mẫu, Mặt tiền

Creational: Factory, Prototype, Builder, Dependency Injection

Ngoại vi: Nhà máy trừu tượng, Khách truy cập, Nhà trang trí, Người hòa giải, Đối tượng loại, Đối tượng không, Đối tượng mở rộng

Khác: Flykg, Phiên dịch

— akuhn
nguồn

Tại sao bạn hạ thấp tôi? Hãy giải thích trong một bình luận để tôi có thể cải thiện câu trả lời.

— akuhn

3

Các mẫu thực tế trong cuốn sách đôi khi thực sự hữu ích, nhưng chúng thực sự chỉ là một công cụ mạnh mẽ hơn mà cuốn sách mang lại cho bạn: hiểu sâu sắc về thời điểm và nơi tốt hơn để cắt mã nguyên khối trong các phần độc lập được phân tách và điều chỉnh bởi giao diện .

Khi bạn học kỹ năng đó, bạn nhận ra rằng bạn không cần phải nhớ chi tiết chính xác của từng mẫu, vì bạn luôn có thể cắt giải pháp bạn đang thực hiện theo cách phù hợp nhất với mục đích của nó. Vì vậy, ý tưởng viết ra ngày càng nhiều mẫu có vẻ rất hàn lâm và vô nghĩa.

— lud1977
nguồn

Điểm tốt, tuy nhiên tôi nghi ngờ rằng nhiều người hiểu cuốn sách (hoặc các mẫu nói chung) theo cách đó.

— Frank Puffer

@ lud1977 nếu chúng ta không ghi lại lịch sử, điều gì ngăn cản tương lai rơi vào cùng một cái bẫy? do đó, nó phải luôn luôn được ghi lại. nó không vô nghĩa.

— r3wt

2

Vì vậy, tôi hy vọng số lượng các mẫu thiết kế đã biết và được ghi nhận sẽ tăng lên đáng kể.

Nó đã không xảy ra. Hơn 20 năm sau khi cuốn sách GoF ra mắt, chỉ có 12 mẫu bổ sung được liệt kê trong bài viết Wikipedia, hầu hết chúng ít phổ biến hơn nhiều so với bản gốc. (Tôi không bao gồm các mẫu đồng thời ở đây vì chúng bao gồm một chủ đề cụ thể.)

Cuốn sách GoF và Wikipedia hầu như không phải là nguồn duy nhất của các mẫu thiết kế đã biết. Nếu bạn chỉ tìm kiếm "mẫu thiết kế" trong Amazon.com, bạn sẽ nhận được hàng trăm cuốn sách (hãy thử tìm kiếm này ). Tôi đoán họ chỉ liệt kê các mẫu được biết đến nhiều nhất trong bài viết Wikipedia .

Vì vậy, vấn đề không phải là không có đủ các mẫu thiết kế được ghi lại. Thay vào đó có rất nhiều mà không ai có thể ghi nhớ tất cả và hầu hết các lập trình viên chỉ nhận ra một số ít. Lời hứa lớn của ngôn ngữ mẫu chung bị phá vỡ vào thời điểm này.

— iluwatar
nguồn

-1

Có lẽ có rất nhiều cấu trúc chưa được nghĩ đến. Miễn là mọi người đang phát triển phần mềm, sẽ có những thách thức thiết kế để vượt qua. Một số trong số đó có thể được giải quyết bằng cách sử dụng các mẫu mới thông minh mà những người khác có thể sử dụng.

Các ngôn ngữ lập trình đã phát triển và tiến triển để trừu tượng hóa các mẫu được sử dụng phổ biến nhất. Những mẫu đó vẫn tồn tại trong thiết kế của các ngôn ngữ. Vì vậy, chúng có thể bị bỏ qua ngày hôm nay, nhưng điều đó không làm cho chúng không quan trọng.

Là kiến thức về cách xây dựng một ngôi nhà đột nhiên không quan trọng một khi chúng ta có robot có thể làm điều đó cho chúng ta? Tôi sẽ tranh luận không, nó không phải là. Nó ít liên quan, chắc chắn - và có lẽ ít đáng để học hơn, vì nhu cầu đã giảm mạnh, và không ai khác nghiên cứu về nó.

Vì vậy, không, tôi không tin không gian mẫu như bạn gọi nó đã cạn kiệt. Như một câu trả lời khác đã chỉ ra, nó có khả năng là vô hạn. Nhưng khi nhu cầu thiết kế hệ thống giảm xuống, khi chúng ta tăng chiều cao của tòa tháp trừu tượng và sức mạnh của ngôn ngữ lập trình của chúng ta - ngày càng ít người xây dựng trên các tầng trên cùng sẽ chú ý đến các chi tiết về cách tòa tháp được xây dựng .

— Tim
nguồn

-2

Các mẫu là vô hạn .. Bạn có thể điều chỉnh từng mẫu hoặc trộn n khớp để tạo mẫu mới .. Các mẫu tích hợp doanh nghiệp cũng được xác định rõ .. vì vậy, gof đã làm đau các tài liệu mẫu bằng cách sử dụng uml và tạo ra một tiêu chuẩn để giải thích chúng .. Nhưng cho mỗi mẫu miền phát triển và chúng cũng thay đổi cho ngôn ngữ biểu cảm như python hoặc scala ..

— Marut Singh
nguồn