Nếu tôi không sử dụng Mẫu thiết kế phần mềm thì sao? [đóng cửa]


17

Tôi có thể gặp phải loại vấn đề gì nếu tôi không sử dụng Mẫu thiết kế phần mềm? Bạn có thể cho tôi biết về các vấn đề tiếp cận thiết kế bằng cách sử dụng các kỹ thuật hướng đối tượng tiêu chuẩn?


24
Khá nhiều mẫu thiết kế phần mềm khá rõ ràng. Bạn sẽ phải biết rất rõ về chúng để chắc chắn rằng bạn không sử dụng chúng - có lẽ cũng đủ để bạn có thể sử dụng chúng!
James McLeod

18
Là một điểm phụ của @JamesMcLeod, nhiều "Mẫu thiết kế" rất rõ ràng và mọi người sẽ làm mọi cách. Tại sao chúng ta đặt tên cho họ, sau đó? Đối với mục đích giao tiếp. "Tôi đang sử dụng mẫu X" có mật độ ngữ nghĩa lớn hơn nhiều so với việc giải thích giải pháp của bạn với hy vọng đầu kia sẽ đi "Ồ vâng! Tôi cũng đã làm điều đó, ngoại trừ tôi đã gọi các biến của mình ...".
Phoshi

6
@AJMansfield Một số mã tồi tệ nhất tôi từng thấy liên quan đến sự nhiệt tình đối với các mẫu thiết kế.
Erik Reppen

5
@ErikReppen đổ lỗi cho việc lạm dụng các mẫu thiết kế nên được quy cho người thực hiện nó. Từ quan điểm của tôi, vấn đề cốt lõi không nằm ở bản thân các mẫu thiết kế, mà là sự khái quát hóa quá mức (một phần do thiếu sự giám sát kiến ​​trúc) và kỹ thuật quá mức (đôi khi do các ủy ban kỹ sư).
rwong

5
"Mẫu thiết kế" là một từ vựng, không phải là một kỹ thuật.
Kaz Dragon

Câu trả lời:


76

Bạn đang thiếu điểm.

Các mẫu thiết kế vốn đã tồn tại khi thực hiện thiết kế phần mềm, giống như các mẫu cấu trúc tồn tại trên thế giới. Ngay cả khi bạn không biết tên của sự vật, cuối cùng bạn sẽ thấy rằng các cấu trúc vật lý nhất định rất phù hợp cho một số vấn đề nhất định. Bạn sẽ thấy rằng hình dạng tam giác của thanh gỗ / kim loại / vv là một cấu trúc rất ổn định, nhưng chỉ trên một mặt phẳng. Bạn sẽ thấy gạch vuông có những lợi thế nhất định so với những viên tròn ...

Tương tự, các cấu trúc phần mềm nhất định theo một cách nào đó là duy nhất hoặc tối ưu. Cuối cùng bạn sẽ tìm thấy chúng và sử dụng chúng bất kể bạn biết tên của chúng. Đó là cốt lõi của các mẫu thiết kế là gì - chúng là tên của các cấu trúc này mà các lập trình viên có kinh nghiệm biết và sử dụng mọi cách. Nó cung cấp cho các lập trình viên khả năng giao tiếp đồng đều và ngắn gọn hơn nhiều. Nó cũng cho phép các lập trình viên suy nghĩ trong các khái niệm về các mẫu có ý thức hơn.

Vì vậy, hai điểm chính tôi đang cố gắng thực hiện:

  1. Bạn không thể sử dụng các mẫu thiết kế.
  2. Khi không biết tên cho những thứ bạn đang sử dụng, bạn sẽ có một thời gian khó khăn khi làm việc trong một nhóm.

12
+1: Hoàn toàn đúng. Tôi bắt đầu phát triển OO trước khi các mẫu thiết kế được biết đến hoặc phổ biến. Vâng, chúng tôi cũng đã phát minh ra những thứ như nhà máy, singletons và một cái gì đó, khi bạn nheo mắt nhìn nó trong một ánh sáng rực rỡ trông giống như mô hình Chiến lược. Vấn đề bây giờ mà tôi biết các mẫu thiết kế tôi biết các nhà máy là OK nhưng có thể đã được thực hiện tốt hơn, các Singletons bị ảnh hưởng nặng thực hiện và những gì là có thể đã là một mô hình chiến lược sẽ tốt hơn nhiều nếu nó thực sự đã là một mô hình chiến lược.
Nhị phân nhị phân

3
... Học về các mẫu thiết kế và học cách sử dụng chúng một cách chính xác giúp bạn tiết kiệm rất nhiều thời gian, bạn ít có khả năng thử phát minh lại bánh xe, ngăn bạn dẫn mình xuống một con đường hướng tới thiết kế tồi và xây dựng các giải pháp tồi. Mút nó và tìm hiểu các mẫu, sử dụng chúng khi chúng làm việc cho bạn và không sử dụng chúng khi chúng không.
Nhị phân nhị phân

1
Và điều này tổng hợp chính xác quan điểm của tôi về các mẫu. Chúng là những công cụ tuyệt vời để truyền đạt những gì bạn đang làm với người khác. Bạn không bao giờ xây dựng chúng chính xác bởi vì mọi vấn đề đều khác nhau. Nhưng chúng là một ý chính, một định hướng và một bộ hướng dẫn sơ bộ cần tuân theo và nó giúp bạn dễ dàng giải thích cho người khác biết bạn đang làm cái quái gì.
Matt D

+1 để so sánh với các cấu trúc vật lý. Tôi sẽ nói thêm rằng nó giúp xây dựng một ngôi nhà nếu bạn đã biết rằng "giàn" là một cấu trúc tốt để hỗ trợ tải trọng của mái nhà, thay vì thử nghiệm và hy vọng rằng nó không sụp đổ.
kdgregory

39

Những người không thể nhớ lại quá khứ bị kết án để lặp lại nó.

Bạn sẽ không phải đối mặt với bất kỳ vấn đề cụ thể nào ngoài những vấn đề do thiết kế của bạn nêu ra. Và trong thời gian bạn sẽ kết thúc việc sử dụng các mẫu mà không nhận thức được, bạn chỉ cần dành thời gian để tự mình tìm ra chúng. Biết các mẫu trước giúp chúng dễ dàng phát hiện hơn trong thiết kế và mang lợi thế lớn mà chúng được chứng minh bởi một số cá nhân.

Tất cả mọi thứ đang được phát triển ngày nay chủ yếu dựa trên kiến ​​thức trước đây, sẽ không có ý nghĩa gì nếu bỏ qua nó. Hãy tưởng tượng việc xây dựng một tòa nhà chọc trời ngày nay mà không biết những vấn đề mà những người xây dựng thánh đường phải đối mặt hàng trăm năm trước.


10
"Mỗi trích dẫn có một unquote bằng nhau và ngược lại." "Chúng ta phải xé nát quá khứ nếu chúng ta thực sự xứng đáng với tương lai." (OK rằng một người là Hitler nên có lẽ tốt nhất nên bỏ qua nó ....)
Russell

20

Tôi có thể gặp phải loại vấn đề gì nếu tôi không sử dụng Mẫu thiết kế phần mềm?

Bạn sẽ gặp vấn đề là không thể viết bất kỳ phần mềm nào.

Biến là một mẫu thiết kế.

Phương pháp là một mẫu thiết kế.

Toán tử - phép cộng, phép trừ, v.v. - là một mẫu thiết kế.

Báo cáo là một mẫu thiết kế.

Giá trị là một mẫu thiết kế.

Tài liệu tham khảo là một mẫu thiết kế.

Biểu hiện là một mẫu thiết kế.

Các lớp học là một mẫu thiết kế.

...

Tất cả mọi thứ bạn làm trong lập trình mọi lúc là một mẫu thiết kế . Hầu hết thời gian mô hình đã ăn sâu vào suy nghĩ của bạn đến nỗi bạn đã ngừng nghĩ về nó như là "một mẫu thiết kế". Những thứ mà bạn phải học như "mẫu đơn" v.v ... chỉ đơn giản là những mẫu chưa (chưa) được đưa vào bất kỳ ngôn ngữ nào bạn đang sử dụng.

Bạn có thể cho tôi biết về các vấn đề tiếp cận thiết kế bằng cách sử dụng các kỹ thuật hướng đối tượng tiêu chuẩn?

Không. Tôi không biết câu hỏi này có nghĩa gì. Các mẫu thiết kế "các kỹ thuật hướng đối tượng tiêu chuẩn" - đó là những gì làm cho chúng thiết kế các mẫu . Mẫu thiết kế là một kỹ thuật tiêu chuẩn để giải quyết một vấn đề cụ thể, đặc biệt (mặc dù không nhất thiết ) trong một ngôn ngữ hướng đối tượng.


1
The things that you have to learn like "the singleton pattern" and so on are simply patterns that haven't (yet) been baked into whatever language you're using.- Đó là (gần như) định nghĩa của một mẫu thiết kế - một cấu trúc mã linh hoạt / dễ sử dụng lại được sử dụng để vượt qua giới hạn trong chính ngôn ngữ, dễ dàng giao tiếp với người khác. Khi nó là một phần của ngôn ngữ, nó không còn là một mẫu thiết kế nữa.
Izkata

1
@Izkata: Vì vậy, vị trí của bạn là như vậy, giả sử, mẫu người quan sát là không thể trong C # vì C # có mẫu người quan sát được xây dựng trong ngôn ngữ ở dạng sự kiện? Điều đó thật ngớ ngẩn. Bit dành riêng cho ngôn ngữ có liên quan đến một mẫu là cách chính tắc để triển khai mẫu trong ngôn ngữ. Tất nhiên các mẫu thiết kế có thể được sử dụng trong các ngôn ngữ hỗ trợ chúng trực tiếp; đó là toàn bộ quan điểm hỗ trợ họ trực tiếp!
Eric Lippert

Tôi không bao giờ nói không thể, tôi đã cố gắng ngụ ý không cần thiết . Ví dụ , Java không có các sự kiện nên nó sử dụng mẫu thiết kế để mô phỏng chúng.
Izkata

@Izkata: Tôi bối rối rồi. Bạn nói rằng một khi một mẫu là một phần của ngôn ngữ thì nó không còn là một mẫu nữa. Vậy "mẫu quan sát viên" có phải là mẫu trong Java nhưng không phải là mẫu trong C # không?
Eric Lippert

1
Hay nói cách khác, một mẫu thiết kế là bất cứ điều gì một lập trình viên làm, hơn là có thể được mô tả bằng tiếng Anh. Tôi không chắc chắn tôi hoàn toàn đồng ý với định nghĩa này, nhưng tôi nghĩ nó phản ánh chính xác những gì bạn đang nói và ít nhất có lợi ích của việc không phán xét chủ quan được coi là một mô hình. Đây là một tài sản phân tích những gì lập trình viên làm, và tất nhiên không thể lập trình viên hành động theo cách không thể phân tích :-)
Steve Jessop

4

Hiểu điểm của một mẫu thiết kế quan trọng hơn việc sử dụng nó cho chữ cái. Một số mẫu là, IMO, ngớ ngẩn, ít nhất là trong các mô hình ngôn ngữ mà tôi quen thuộc. IMO, một lập trình viên chỉ đơn giản sử dụng các mẫu thiết kế một cách mù quáng và không thực sự hiểu chúng là một lập trình viên tồi tệ hơn so với người muốn tự mình suy nghĩ mọi thứ. Nhưng ai đó tự làm quen với các ý tưởng và sau đó tự quyết định xem liệu chúng có giá trị có khả năng trở thành một lập trình viên mạnh hơn nhiều không.

Điều đó nói rằng, tôi không có! @ # $ Ing ý tưởng điểm cân nặng là gì và tôi không xấu hổ khi thừa nhận điều đó. (xem bình luận cho một mục wikipedia khác đã giúp rất nhiều)

Tôi đề nghị mục của wikipedia về các mẫu thiết kế. Nó được viết rất chính xác và rõ ràng. Rất hữu ích để có được một ý tưởng về lý do tại sao một người có thể bận tâm với một mẫu thiết kế nhất định hay không. Cá nhân tôi có xu hướng tìm ra những cái đơn giản nhất hữu ích nhất và sẽ không nghĩ hai lần về việc sửa đổi một triển khai nhất định của bất kỳ mẫu nào cho phù hợp với nhu cầu của tôi.

Chúng là những ý tưởng, không phải bản thiết kế. Trong một số ngôn ngữ, chúng không phải là ý tưởng hay. Ở những người khác, họ được coi là những người không thể khắc phục được những điểm yếu trong thiết kế ngôn ngữ có thể được bù đắp tốt hơn thông qua sự phức tạp ít hơn. Bất kể, việc kiểm tra chúng và cố gắng hiểu những thách thức mà chúng phải vượt qua trước khi quyết định các giải pháp ưa thích của bạn là điều không hại.

Những loại vấn đề bạn sẽ phải đối mặt? Bạn có thể bỏ lỡ các cơ hội và dành nhiều thời gian cho các vấn đề hơn mức cần thiết trừ khi bạn là một thiên tài lập trình, người đã tìm ra tất cả. Điều quan trọng là duy trì một con mắt quan trọng của các ý tưởng lập trình phổ biến nhưng không bao giờ đau lòng để hiểu những gì mọi người nghĩ họ đang giải quyết vì điều đó sẽ cho vay rõ ràng hơn các giải pháp / phương pháp ưa thích của riêng bạn.


2
bánh đà (không phải bánh đà). Đọc đoạn đầu tiên (và chỉ đoạn đầu tiên) của bài viết wikipedia và sau đó xem Integer.valueOf (int) và xem xét bao nhiêu lần điều này tránh tạo ra số nguyên mới cho các giá trị chung.

2
@MichaelT Và chết tiệt. Điều đó đã đánh vần nó ra một địa ngục tốt hơn nhiều so với bất cứ điều gì tôi đã thấy. Cảm ơn.
Erik Reppen

Vấn đề mà tôi thấy với hầu hết các hướng dẫn mẫu thiết kế là họ cố gắng đưa ra một cái nhìn dự án lớn (cuốn sách GoF hoàn toàn là về việc viết một trình xử lý văn bản - không phải là một nhiệm vụ nhỏ). Nhưng đôi khi chúng có thể áp dụng cho những thứ nhỏ hơn (gần như 'tầm thường'). 7 dòng mã có thể mô tả rõ ràng về trọng lượng trong một thứ mà mọi người sử dụng liên tục. Dễ hiểu hơn nhiều so với các dự án lớn hoặc các ví dụ giả định.

1
@MichaelT Đối với tôi, đó cũng là một ví dụ điển hình về việc làm rõ một chút gì đó về cách viết mã nói chung ngay cả khi ý tưởng đó không được sử dụng ngay trong ngôn ngữ chính của tôi, JavaScript, nơi kế thừa và đóng cửa nguyên mẫu thường được sử dụng để giải quyết điều đó vấn đề. Có một khoảnh khắc a-ha vẫn cho tôi một số ý tưởng có liên quan.
Erik Reppen

2

Vấn đề chính bạn sẽ gặp phải là bạn sẽ phát minh lại bánh xe . Chúng được gọi là các mẫu vì chúng xuất hiện thường xuyên và theo cách có thể dự đoán được.


0

Ngay cả khi bạn làm theo các mẫu thiết kế, bạn có thể sẽ có một thiết kế xấu. Các mẫu thiết kế là tự nhiên và cuối cùng bạn sẽ sử dụng một số hương vị của nó trong thiết kế của bạn. Bạn sẽ phải cố gắng rất nhiều để không sử dụng bất kỳ mẫu nào. Không có lý do để lên án các mẫu thiết kế, điều quan trọng hơn là chọn các mẫu phù hợp với nhu cầu của bạn


-1

Bạn đang sử dụng các mẫu thiết kế mọi lúc mà không nhận ra nó. Rất nhiều thư viện tiêu chuẩn trong các ngôn ngữ phổ biến được thiết kế với các mẫu thiết kế trong tâm trí. Một ví dụ là FileReaderthư viện của Java được thiết kế bằng mẫu thiết kế trang trí . Bây giờ nói về mã của riêng bạn, bạn không bị buộc phải sử dụng các mẫu thiết kế (trong hầu hết các trường hợp). Mẫu thiết kế là "giải pháp có thể tái sử dụng cho một vấn đề thường xảy ra" , có nghĩa là nó sẽ giúp bạn viết mã dễ bảo trì hơn để bạn thực sự muốn tránh kết thúc với mã spaghetti.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.