it-swarm-vi.com

Khi nào tôi nên sử dụng và không sử dụng các mẫu thiết kế của Haiti?

Trong một câu hỏi trước đây của tôi về Stack Overflow , FredOverflow được đề cập trong các nhận xét:

Lưu ý rằng các mẫu không cải thiện một cách kỳ diệu chất lượng mã của bạn.

Bất kỳ thước đo chất lượng bạn có thể tưởng tượng. Các mô hình không phải là thuốc chữa bách bệnh. Tôi đã từng viết một trò chơi Tetris với khoảng 100 lớp kết hợp tất cả các mẫu tôi biết vào thời điểm đó. Tại sao sử dụng một if/other đơn giản nếu bạn có thể sử dụng một mẫu? OO là tốt, và các mẫu thậm chí còn tốt hơn, phải không? Không, đó là một mảnh tồi tệ, quá kỹ thuật.

Tôi khá bối rối trước những bình luận này: Tôi biết các mẫu thiết kế giúp làm cho mã có thể sử dụng lại và có thể đọc được, nhưng khi nào tôi nên sử dụng các mẫu thiết kế và có lẽ quan trọng hơn, khi nào tôi nên tránh mang theo chúng?

57
ashmish2

HÔN trước, mẫu sau, có thể nhiều sau. Một mô hình là một trạng thái của tâm trí, chủ yếu. Đừng bao giờ cố gắng ép mã của bạn vào một mẫu cụ thể, thay vào đó hãy chú ý những mẫu nào bắt đầu kết tinh từ mã của bạn và giúp chúng theo một chút.

Quyết định "ok, tôi sẽ viết một chương trình X sử dụng mẫu Y" là một công thức cho thảm họa. Nó có thể hoạt động cho các chương trình đẳng cấp thế giới phù hợp để trình diễn các cấu trúc mã cho các mẫu, nhưng không nhiều hơn thế.

99
jwenting

Tôi nghĩ rằng mối quan tâm chính là mọi người thường có xu hướng lạm dụng các mẫu thiết kế. Họ học được một ít, thấy được sự hữu ích của chúng, và không nhận ra điều đó đã biến vài mẫu đó thành một loại búa vàng mà sau đó chúng áp dụng cho mọi thứ.

Chìa khóa không nhất thiết phải tự học các mẫu. Điều quan trọng là học cách xác định các kịch bản và vấn đề mà các mẫu có ý nghĩa để giải quyết. Sau đó, áp dụng mô hình chỉ đơn giản là vấn đề sử dụng công cụ phù hợp cho công việc. Đó là công việc phải được xác định và hiểu trước khi chọn công cụ.

Và đôi khi đó là một thiết lập kỳ quặc và không có mô hình cắt và khô để giải quyết nó ngay lập tức. Tại thời điểm đó cần chú ý nhiều hơn đến vấn đề hơn là giải pháp. Chia nó thành các vấn đề thành phần, xác định các khu vực của vấn đề chia sẻ các đặc điểm chung với các vấn đề được giải quyết theo các mẫu đã biết, điều chỉnh các mẫu để phù hợp với vấn đề, v.v.

52
David

Một mẫu thiết kế hoạt động tốt nhất khi nó được sử dụng như một ngôn ngữ chung trong nhóm của bạn.

Ý tôi là, bạn có thể nói một cái gì đó như "lớp này là một Singleton thực hiện IHurineWidget Nhà máy trừu tượng " và mọi người trong nhóm của bạn hiểu điều đó có nghĩa là gì mà không cần phải đi vào giải thích chi tiết.

Trường hợp các mẫu thiết kế thất bại là khi nhóm không hiểu chúng hoặc khi chúng bị lạm dụng quá nhiều đến nỗi chúng ngừng làm cho thiết kế rõ ràng hơn và thay vào đó làm cho khó hiểu hơn những gì đang thực sự xảy ra.

24
GrahamS

có thể hơi lạc đề, nhưng tôi nghĩ nó cũng bao gồm câu hỏi của bạn: Tôi sẽ gợi ý cho bạn một cuốn sách hay Tái cấu trúc các mẫ :

Cuốn sách này giới thiệu lý thuyết và thực hành về tái cấu trúc theo hướng mẫu: chuỗi các phép tái cấu trúc mức thấp cho phép các nhà thiết kế di chuyển một cách an toàn các thiết kế để, hướng tới hoặc tránh xa các triển khai mẫu . Sử dụng mã từ các dự án trong thế giới thực, Kerievsky ghi lại tư duy và các bước làm cơ sở cho hơn hai chục biến đổi thiết kế dựa trên mẫu. Trên đường đi, ông đưa ra những hiểu biết sâu sắc về sự khác biệt của mẫu và cách triển khai các mẫu theo những cách đơn giản nhất có thể.

bạn sẽ tìm thấy các ví dụ khi các mẫu thiết kế được sử dụng tốt, cũng như khi bạn cần loại bỏ chúng, không làm cho ứng dụng bị quá phức tạp. Và vâng, ý tưởng chính là giữ mọi thứ đơn giản nhất có thể.

Câu trả lời/lời khuyên tốt cho câu hỏi của bạn là trong bài viết Bạn có nhận ra 4 dấu hiệu cảnh báo sớm về lạm dụng mẫu thiết kế không? , nhưng tôi không thể tải nó ngay bây giờ, lỗi 500. Nó không lớn, vì vậy tôi không chỉ cần sử dụng google cache để lấy nó:

Các mẫu thiết kế phần mềm có thể và dẫn đến kỹ thuật quá mức

Quá kỹ thuật là quá trình phức tạp hóa một cái gì đó. Trong trường hợp lập trình, làm cho mã của bạn phức tạp hơn và có thể linh hoạt hơn mức cần thiết. Cụ thể hơn, thực hiện các mẫu thiết kế phần mềm phức tạp về các vấn đề đơn giản.

1. Bắt đầu đơn giản không phức tạp

Làm thế nào điều này xảy ra? Thông thường, bạn lập trình trong chức năng bổ sung mà bạn dự đoán sẽ được sử dụng hoặc chứng minh là hữu ích sau này. Nhưng điều gì xảy ra nếu nhu cầu này không bao giờ thành hiện thực? Trong hầu hết các trường hợp, cruft được để lại ở đó. Nó không được loại bỏ. Vì vậy, hệ thống phần mềm tiếp tục phát triển về quy mô và độ phức tạp với tất cả các tính năng mà Aren từng được sử dụng.

2. Hãy cảnh giác với các dấu hiệu

Điều này có lẽ khác với mọi người nhưng tôi nghi ngờ trong hầu hết các trường hợp, đó thực sự là một nỗ lực có ý thức. Nhưng đúng hơn, đó là một cái gì đó mang lại bởi nỗi sợ bị mắc kẹt với một thiết kế vụng về, không phù hợp, không phù hợp hoặc đơn giản, xấu; bị mắc kẹt với một cái gì đó vừa đủ linh hoạt. Trớ trêu thay, nếu bạn đạt đến điểm vượt qua kỹ thuật hoặc áp dụng các mô hình, bạn sẽ quay lại ngay nơi bạn bắt đầu.

Các mẫu thiết kế phần mềm thu hút các lập trình viên hoặc nhà phát triển vì chúng cho phép chúng thể hiện một cách tự nhiên và tạo ra các kiến ​​trúc đẹp. Đó là một phần của việc thưởng thức chương trình sáng tạo.

3. Xem xét tái cấu trúc theo một mẫu thay vì bắt đầu từ một

Điều gì có thể là một cách tốt để tránh lạm dụng mẫu thiết kế này? Xem xét tái cấu trúc theo một mô hình thay vì bắt đầu từ một mô hình. Donith bắt đầu cố gắng buộc một mô hình vào thiết kế của bạn. Rất có thể thiết kế của bạn có thể đơn giản hơn nhiều nếu không có nó. Nếu bạn thấy ở giai đoạn sau đó, thiết kế của bạn thực sự có thể được hưởng lợi từ một mẫu có cấu trúc, thì hãy cấu trúc lại để cho phép nó. Khi bạn thiết kế, giải quyết vấn đề theo cách đơn giản nhất có thể. Phần mềm trọng lượng nhẹ đơn giản luôn là một điều tốt. Có nhiều cách tốt hơn để tránh sự thay thế được thiết kế dưới mức mà bạn bị mắc kẹt với một thiết kế hoặc giải pháp chỉ cần linh hoạt đủ linh hoạt hoặc không phù hợp với vấn đề.

4. Don lồng buộc bản thân phải làm cho đúng ngay lần đầu tiên

Buộc các mẫu hoặc cấu trúc thiết kế phần mềm vào thiết kế không phải là câu trả lời, đó chỉ là thiết kế tồi. Nhưng tạo mẫu hoặc xây dựng một build0 ban đầu (bằng chứng xây dựng khái niệm trước khi bắt đầu sản xuất sản phẩm thực tế) có thể giúp tránh điều này và vấn đề của kỹ thuật quá mức. Bởi vì bạn không cảm thấy như bạn phải làm cho nó hoàn toàn đúng ngay lần đầu tiên.

URL gốc (hiện đã chết): http://codelines.net.au/article/do-you-recognise-the-4-early-warning-signs-of-design-potype-abuse/

14
Maxym

khi nào nên ngừng làm mọi thứ bằng cách sử dụng các mẫu?

Câu hỏi là khi nào bạn bắt đầu thực hiện mọi thứ bằng cách sử dụng các mẫu? Không phải tất cả các giải pháp đều phù hợp với một mẫu thiết kế hiện có và việc áp dụng một mẫu có thể có nghĩa là bạn làm vẩn đục sự sạch sẽ của giải pháp của bạn. Bạn có thể thấy rằng thay vì mẫu thiết kế giải quyết vấn đề của bạn, bạn sẽ tạo ra một vấn đề khác bằng cách cố gắng buộc giải pháp của bạn để phù hợp một mẫu thiết kế.

Rõ ràng, nếu bạn chọn mẫu thiết kế chính xác cho một kịch bản cụ thể thì bạn sẽ không gặp vấn đề gì, tuy nhiên, chọn mẫu chính xác thì nói dễ hơn làm.

Tôi đã thấy việc lạm dụng các mẫu trong các dự án mà chúng thực sự không cần thiết.

Tôi nghĩ rằng khóa là - Cố gắng giữ mã của bạn sạch sẽ, mô-đun và có thể đọc được và đảm bảo rằng các lớp của bạn không liên kết chặt chẽ =. Cuối cùng, bạn có thể thấy rằng bạn đã vô tình sử dụng một biến thể trên một mẫu thiết kế tiêu chuẩn. Có lẽ bạn sẽ nhận ra điều này khi bắt đầu dự án của bạn trước khi bạn bắt đầu viết mã. Nếu bạn viết mã như hầu hết những người tôi biết (bao gồm cả bản thân mình), thì có lẽ là không :)

9
El Ronnoco

Chà, điều quan trọng nhất là phải biết vấn đề mà bạn đang giải quyết. Hơn bạn cần phải quyết định xem việc giới thiệu một số mẫu sẽ mang lại cho bạn một số lợi thế so với việc không sử dụng nó (đạt được về hiệu suất, sự đơn giản hoặc bất cứ điều gì). Các câu hỏi liên quan: https://stackoverflow.com/questions/85272/how-do-you-ledge-when-to-use-design-potypes

5
sinek

Không. về các mẫu thiết kế được đề cập trong văn bản gốc/thực tế về chủ đề này, tức là GoF đòi hỏi khá nhiều kinh nghiệm và thường đọc lại và gây bão với các đồng nghiệp có năng lực để thành thạo. Đăng giai đoạn đó, đưa ra một vấn đề, đưa ra một kiến ​​trúc, thường là các mẫu thiết kế tự nhiên nhất xuất hiện theo cách khá rõ ràng. Tuy nhiên, bất kỳ nỗ lực nào phù hợp với mô hình thiết kế phù hợp với các vấn đề, hoặc các vấn đề ánh xạ đối với các mẫu thiết kế đều gây nguy hiểm, trong trường hợp tốt nhất là tham khảo ý kiến ​​các chuyên gia, bão não một chút và coi đó là kinh nghiệm học tập. Trừ khi bạn khá thoải mái với các mẫu thiết kế 10 số thường được sử dụng, điều này sẽ vẫn còn một chút khó khăn và AFAIK, không có phím tắt.

Tôi đã đi qua hàng triệu dự án mã SLOC C++ với các ví dụ phong phú về các mẫu thiết kế phù hợp với lực lượng, vì vậy sai lầm s.a. lạm dụng không quá phổ biến.

4
icarus74

Nó giống như thế này với bất kỳ chủ đề nào yêu cầu bạn tìm hiểu và áp dụng các quy tắc :

  1. Nếu bạn là người mới, bạn cần tuân theo các quy tắc vì bạn không biết rõ hơn.
  2. Nếu bạn là một người nghiệp dư, bạn làm theo các vai trò bởi vì bạn biết tại sao bạn cần chúng.
  3. Nếu bạn là một người chuyên nghiệp, bạn làm việc với các quy tắc hơn là chống lại chúng, biết rõ nên sử dụng ở đâu và khi nào chúng không áp dụng.
  4. Nếu bạn là một chuyên gia, bạn bỏ qua các quy tắc.
  5. Nếu bạn đã thành thạo nghệ thuật của mình, bạn thích các quy tắc vì mã của bạn cũng phải được nhìn thấy bởi loại 1-3 người. :)

Điều đó cũng tương tự với võ thuật, hội họa, viết lách, bóng đá, cơ khí, đua xe, v.v ...

Là một chàng trai số 5, cuối cùng bạn thường dạy cho các chàng trai # 1- # 4 cách trở thành người đứng đầu, vì vậy nó luôn được áp dụng, ngay cả trong bối cảnh cạnh tranh.

( Cách chuyển đổi và bỏ qua các quy tắc giải thích điều này theo nghĩa chung, nhưng có lẽ có những bài tiểu luận tốt hơn ngoài kia.)

4
Macke

Quy tắc là không có quy tắc. Kinh nghiệm của bạn (thành công hơn thất bại) sẽ cho bạn biết khi nào nên sử dụng chúng hoàn toàn, khi nào nên thích nghi với chúng hoặc khi nào không nên sử dụng chúng.

Có một thuyết trình bởi Dan North, trong đó anh ấy nói một chút về học tập và mô hình

3
Augusto

Giữ mọi thứ đơn giản nhất có thể. Tuy nhiên, bạn phải giải quyết một vấn đề, tuy nhiên, bạn có thể muốn sử dụng một mẫu thiết kế, tuy nhiên, thay vì phát minh lại bánh xe, vì nhiều mẫu thiết kế cung cấp giải pháp cho các vấn đề phổ biến. Nhưng như tôi đã nói: chỉ sử dụng chúng khi thực sự cần thiết.

2
Puce

Có thể sử dụng KISS DRY mẫu SoC (vâng, có thể đó không phải là mẫu, nhưng nghe có vẻ vui).

Giữ cho nó đơn giản ngu ngốc.
[.__.] Đừng lặp lại chính mình.
[.__.] Tách mối quan tâm.

Tôi nghĩ ba điểm này nên truyền cảm hứng cho bất kỳ lập trình viên nào.

2
Fredrik Norlin

Vấn đề với "mẫu" là bất cứ thứ gì cũng có thể được coi là một mẫu, và thường là vậy.

Tôi đã phát triển mã một cách chuyên nghiệp trong một thời gian dài trước khi tôi nghe bất cứ ai nói về "mẫu" và tôi đã quản lý tốt trong suốt những năm đó. Trong thực tế, khi tôi nhìn lại, rất nhiều thứ tôi viết thực sự tuân theo một số mô hình nổi tiếng, ít nhất là ở một mức độ nào đó.

Quan điểm của tôi là theo bất kỳ mô hình nhất định nào thực sự không phải là câu trả lời. Tìm hiểu về các mẫu mới, nhưng đừng để bản thân bị ràng buộc với chúng: Chúng sẽ thay đổi. Thực hành mã hóa tốt ngày nay không giống như thực hành mã hóa tốt mười năm trước, và cho dù các lập trình viên ngày nay thông minh đến đâu, bạn có thể chắc chắn rằng mười năm nữa trong tương lai, những điều được coi là thực hành tốt ngày nay sẽ được áp dụng.

Chủ đề ngoài lề: Trên một ghi chú cá nhân, tôi thực sự ghét việc sử dụng các 'mẫu' của Word trong ngữ cảnh này. Nó nghĩ về thuật ngữ không cần thiết.

1
Spudley

Các mẫu thiết kế thường được sử dụng để giải thích cho đối tượng rộng hơn những gì mã của bạn thực sự làm. Bằng cách này, nó giúp mọi người dễ dàng hiểu những gì bạn đang làm. Người ta hiếm khi sử dụng nó như một tài liệu tham khảo để đưa ra các giải pháp, vì một mô hình thực sự có thể được thực hiện theo nhiều cách.

0
Gaurav Sehgal

Cách bạn cấu trúc logic của mã của bạn sẽ cho phép người mới sử dụng mã đó có thể diễn giải và sửa đổi nó. Có một mô hình chỉ vì đó là một cách thực hành tốt nhất sẽ không đưa bạn đến bất cứ đâu nếu bạn không hiểu đầy đủ bối cảnh về cách thức, ai và nơi mà mã đó có thể được sử dụng.

Mẫu "Giữ cho nó đơn giản" là một ý nghĩa thông thường hơn là một mẫu và nó phải là một phần của quá trình suy nghĩ của nhà phát triển khi tạo mã. Giả sử rằng tất cả mọi người đều nhận được một mẫu cụ thể cũng không chính xác. Lý tưởng nhất là bạn muốn một mô hình có thể được đọc và xác định mà không có nhiều kiến ​​thức về nó.

0
Oscar Villarreal

Imho bạn sẽ chỉ biết nó. Ý tôi là tôi thậm chí đã sử dụng một mẫu thiết kế trước khi tôi biết định nghĩa của mẫu thiết kế. Nó chỉ là mã hóa tốt. Đôi khi bạn sẽ có thể nhận ra nó trong khi viết các yêu cầu của dự án và đôi khi bạn phải cấu trúc lại mã của mình.

jwenting đã nói HÔN trước, mẫu sau . Tôi nghĩ rằng các mẫu là một cách để [~ # ~] hôn [~ # ~] một dự án vì bạn có thể áp dụng một cái gì đó bạn biết nó hoạt động và sẽ phụ tùng thời gian của bạn trong tương lai.

Điều duy nhất có thể sai là có nhiều cách để thực hiện một mẫu thiết kế duy nhất, ngay cả trong cùng một ngôn ngữ, vì vậy bạn cần hiểu hoàn toàn vấn đề của bạn là gì.

0
dierre