Làm thế nào để xác định xem Mẫu thiết kế có được triển khai chính xác không?

13

Tôi thành công có thể mở rộng tất cả các ứng dụng cũ không sử dụng Mẫu thiết kế tài liệu. Dù là mẫu nào thì tôi cũng không biết. Ở một mức độ lớn, tôi chỉ cảm thấy cần phải sử dụng các khái niệm OOP đơn giản.

Khái niệm Mẫu thiết kế rất phức tạp và khó hiểu. Khi được triển khai, làm thế nào để xác định xem việc triển khai có đúng không và ứng dụng có khớp nối lỏng thực sự không?

design-patterns

— RPK
nguồn

49

Có một quan niệm sai lầm nghiêm trọng về các mẫu thiết kế là gì. Chúng không phải là hạt bụi thần tiên mà bạn rắc lên ứng dụng của mình để làm cho nó tốt hơn. Chúng chủ yếu là một từ vựng phổ biến để có thể nói về những cách thường được sử dụng để giải quyết vấn đề. Tôi khá chắc chắn rằng có nhiều người "thực hiện các mẫu chính xác" cả ngày mà không bao giờ nghe thấy từ "mẫu".

— Joachim Sauer

2

@JoachimSauer Những gì bạn vừa nói là loại công cụ mà các trường đại học kỹ thuật nên dạy ... Vì tôi hiện đang là sinh viên, đây là điều khiến tôi bực mình nhất.

— Radu Murzea

1

@JoachimSauer Trên thực tế, quan niệm sai lầm này xuất hiện bởi vì có nhiều kỹ thuật thực hiện cho cùng một mô hình. Lấy ví dụ MVC và MVP, có nhiều biến thể như các dự án, có cùng mẫu.

— RPK

@RPK +1, thực tế là có rất nhiều mẫu MVX (MVC, MVP, MVA, MVVM, v.v.) nên là một dấu hiệu rõ ràng rằng có nhiều cách khả thi để làm mọi thứ.

— MattDavey

Có thể trùng lặp khi nào tôi nên sử dụng chương trình và không sử dụng các mẫu thiết kế của Haiti?

— gnat

3

Để giữ câu trả lời ngắn gọn, tôi sẽ nói nếu các đặc điểm sau có thể nhìn thấy trong mã của bạn, bạn có thể tin tưởng rằng các mẫu được đặt ngay cả khi bạn không thực hiện các nỗ lực có chủ ý (không phải là vấn đề) đối với nó.

Đặc điểm mong muốn:

Cơ sở mã của bạn có thể kiểm tra được ở cấp đơn vị
Bất cứ khi nào bạn đang thực hiện bất kỳ yêu cầu thay đổi nào thì bạn chỉ thực hiện thay đổi đối với các lớp có liên quan có liên quan trong miền.
Cơ sở mã của bạn không thể hiện entropy phần mềm .

Nếu bạn vẫn tò mò xác định và gắn thẻ mã của mình bằng tên mẫu thực, tôi sẽ khuyên bạn nên thực hiện các hành động sau đây để bắt đầu.

Kỹ sư đảo ngược cơ sở mã của bạn để tạo ra một vài daigram UML.
Trực quan so sánh các sơ đồ với bất kỳ tài liệu tham khảo sẵn sàng nào của tài liệu tham khảo mẫu.

Điều này sẽ cung cấp cho bạn một ý tưởng công bằng.

— Sameer Patil
nguồn

Bạn có thể nói rõ hơn về cái thứ ba?

— Niing

19

Bạn đề cập đến cả hai mẫu thiết kế và khớp nối. Đây là những khái niệm riêng biệt nên tôi sẽ giải quyết chúng một cách riêng biệt. Mối liên hệ thực sự duy nhất là các mẫu thiết kế có xu hướng thúc đẩy khớp nối lỏng lẻo (vì đó là khía cạnh chính của thiết kế tốt).

Mẫu thiết kế

Khái niệm về các mẫu thiết kế thực sự khá đơn giản: Chúng chỉ là một tập hợp các mẫu về cách giải quyết các vấn đề phổ biến khác nhau. Có 2 lý do chính khiến chúng phổ biến:

Chúng được 'chứng minh': chúng đã được sử dụng trước nhiều lần và những lợi ích / hạn chế của từng loại thường được biết đến, đặc biệt là bất kỳ vấn đề tinh tế nào có thể gây ra vấn đề lớn đều được biết đến.
Họ cung cấp một bộ thuật ngữ chung và do đó cho phép giao tiếp dễ dàng hơn. Nếu ai đó nói rằng "lớp X đóng vai trò của người quan sát trong mẫu người quan sát" thì các nhà phát triển đã quen thuộc với mẫu này có thể ngay lập tức nắm bắt được những gì đang diễn ra.

Làm thế nào để bạn biết rằng bạn đã thực hiện nó một cách chính xác? Đó là một điều khó khăn. Đối với hầu hết các mẫu, nó đơn giản - bạn đã mò mẫm nó hoặc bạn chưa. Một số mẫu ít được xác định rõ ràng hơn các mẫu khác - ví dụ: model-view-controller . Các mô hình như thế được sử dụng tốt hơn như hướng dẫn chung. Các chi tiết cụ thể về cách bạn triển khai nó ít quan trọng hơn việc hiểu các lý do mà mô hình tồn tại và ý nghĩa của nó để thực hiện.

Các mẫu thiết kế không phải là "một cách thực sự". Thường thì bạn sẽ cần điều chỉnh chúng cho các mục đích cụ thể của mình hoặc đôi khi sẽ không có bất kỳ mẫu nào phù hợp với yêu cầu. Buộc một mẫu thiết kế nơi nó không phù hợp là một ý tưởng tồi; nó giống như sử dụng một cái búa thực sự tốt khi thứ bạn thực sự muốn là một cái tuốc nơ vít.

Khớp nối

Đây là một ý tưởng thực sự quan trọng trong khoa học máy tính. Vì các yêu cầu cho hầu hết các dự án phần mềm thay đổi theo thời gian (đôi khi đáng kể), nên khả năng thiết kế để đối phó với các thay đổi là rất quan trọng. Khớp nối về cơ bản là thước đo "khó có thể trao đổi thành phần này cho thành phần khác?" 'Thành phần' có thể là một phương thức, lớp, gói, thư viện, v.v.

Có nhiều loại khớp nối được liệt kê trong bài viết Wikipedia này .

— vaughandroid
nguồn

2

Câu trả lời thực sự là mục đích mà bạn muốn viết các mẫu thiết kế từ đầu. Tại sao bạn muốn linh hoạt?

Đó là sự thay đổi; yêu cầu thay đổi. Hãy thử thay đổi một cái gì đó trong các yêu cầu của bạn phản ánh sự thay đổi mã và xem mức độ dễ / khó để làm điều đó.

— m3th0dman
nguồn

-1

Sử dụng các mẫu thiết kế là một hành động phòng ngừa. Bạn sử dụng các thiết kế để dễ dàng thực hiện công việc của bạn khi bạn mở rộng ứng dụng sau này. Tất nhiên, để giảm bớt công việc của bạn sau này, bạn phải làm thêm một chút công việc bây giờ. Vì vậy, câu hỏi thực sự là bạn có thể mong đợi bao nhiêu thay đổi trong tương lai và sự thay đổi này là gì. Nếu bạn không cần khả năng mở rộng và linh hoạt, bạn có thể loại bỏ các mẫu thiết kế.

Các mẫu thiết kế tự chúng là một triển khai của Nguyên tắc Thiết kế Hướng đối tượng. Miễn là bạn tuân theo các nguyên tắc này, các ứng dụng của bạn sẽ linh hoạt và có thể mở rộng; ngay cả khi bạn không thực sự có một mẫu thiết kế thực tế. Như Joachim Sauer đã nhận xét ở trên, chúng là những giải pháp phổ biến cho các vấn đề phổ biến.

— Sở DPD
nguồn

2

IMO, sử dụng các mẫu thiết kế không liên quan gì đến khả năng mở rộng. Nó chỉ đơn giản là một từ vựng để nhận ra các mẫu phổ biến trong mã để chúng ta có thể nói về chúng. Thông thường, các ứng dụng mở rộng có thể có nghĩa là đi ngược lại các thiết kế tốt có lợi cho hiệu suất.

— Adrian Schneider