Một mô hình chống là gì?

Tôi đang nghiên cứu các mẫu và chống mẫu. Tôi có một ý tưởng rõ ràng về các mẫu, nhưng tôi không nhận được các mẫu chống. Các định nghĩa từ web và Wikipedia làm tôi bối rối rất nhiều.

Bất cứ ai có thể giải thích cho tôi bằng những từ đơn giản một mô hình chống là gì? Mục đích là gì? Họ làm gì? Đó là một điều xấu hay tốt?

Chống mẫu là các mẫu nhất định trong phát triển phần mềm được coi là thực tiễn lập trình xấu.

Trái ngược với các mẫu thiết kế là cách tiếp cận phổ biến đối với các vấn đề phổ biến đã được chính thức hóa và thường được coi là một thực tiễn phát triển tốt, các mô hình chống lại ngược lại và không mong muốn.

Ví dụ, trong lập trình hướng đối tượng, ý tưởng là tách phần mềm thành các phần nhỏ gọi là các đối tượng. Một mô hình chống trong lập trình hướng đối tượng là một đối tượng Thiên Chúa thực hiện rất nhiều chức năng sẽ được phân tách tốt hơn thành các đối tượng khác nhau.

Ví dụ:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

Ví dụ trên có một đối tượng làm mọi thứ . Trong lập trình hướng đối tượng, tốt hơn là nên có các trách nhiệm được xác định rõ ràng cho các đối tượng khác nhau để giữ cho mã ít được ghép nối và cuối cùng dễ bảo trì hơn:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

Điểm mấu chốt là có những cách tốt để phát triển phần mềm với các mẫu thường được sử dụng ( mẫu thiết kế ), nhưng cũng có những cách phần mềm được phát triển và triển khai có thể dẫn đến các vấn đề. Các mẫu được coi là thực tiễn phát triển phần mềm xấu là chống mẫu.

Bất cứ khi nào tôi nghe về Anti-samples, tôi nhớ lại một thuật ngữ khác. Thiết kế mùi.

"Mùi thiết kế là một số cấu trúc nhất định trong thiết kế cho thấy sự vi phạm các nguyên tắc thiết kế cơ bản và ảnh hưởng tiêu cực đến chất lượng thiết kế. (Từ" Tái cấu trúc cho mùi thiết kế phần mềm: Quản lý nợ kỹ thuật ")

Có nhiều mùi thiết kế được phân loại dựa trên các nguyên tắc thiết kế vi phạm:

Mùi trừu tượng

Thiếu trừu tượng: Mùi này phát sinh khi các cụm dữ liệu hoặc chuỗi được mã hóa được sử dụng thay vì tạo một lớp hoặc một giao diện.

Trừu tượng bắt buộc: Mùi này phát sinh khi một hoạt động được chuyển thành một lớp.

Trừu tượng không đầy đủ: Mùi này phát sinh khi một sự trừu tượng không hỗ trợ hoàn toàn các phương pháp bổ sung hoặc liên quan đến nhau.

Trừu tượng nhiều mặt: Mùi này phát sinh khi một trừu tượng có nhiều hơn một trách nhiệm được giao cho nó.

Trừu tượng không cần thiết: Mùi này xảy ra khi một sự trừu tượng thực sự không cần thiết (và do đó có thể tránh được) được giới thiệu trong một thiết kế phần mềm.

Trừu tượng không được sử dụng : Mùi này phát sinh khi một sự trừu tượng không được sử dụng (không được sử dụng trực tiếp hoặc không thể tiếp cận).

Trừu tượng trùng lặp: Mùi này phát sinh khi hai hoặc nhiều trừu tượng có tên giống nhau hoặc thực hiện giống hệt nhau hoặc cả hai.

Mùi đóng gói

Thiếu đóng gói: Mùi này xảy ra khi khả năng tiếp cận được tuyên bố của một hoặc nhiều thành viên trừu tượng được cho phép nhiều hơn so với yêu cầu thực sự.

Leaky Encapsulation: Mùi này phát sinh khi một bản tóm tắt, lộ ra các chi tiết triển khai trên truyền hình trực tuyến và thông tin công khai thông qua giao diện công cộng.

Thiếu đóng gói: Mùi này xảy ra khi các biến thể thực hiện không được gói gọn trong một sự trừu tượng hoặc phân cấp.

Đóng gói chưa được khai thác: Mùi này phát sinh khi mã máy khách sử dụng kiểm tra loại rõ ràng (sử dụng các câu lệnh if-other hoặc switch để kiểm tra loại đối tượng) thay vì khai thác biến thể trong các loại đã được gói gọn trong một hệ thống phân cấp.

Modularization mùi

Mô-đun bị hỏng: Mùi này phát sinh khi dữ liệu và / hoặc phương pháp lý tưởng nên được định vị thành một trừu tượng duy nhất được tách ra và trải rộng trên nhiều trừu tượng.

Modularization không đủ: Mùi này phát sinh khi một sự trừu tượng tồn tại chưa được phân hủy hoàn toàn, và một sự phân hủy tiếp theo có thể làm giảm kích thước của nó, độ phức tạp thực hiện hoặc cả hai.

Modularization phụ thuộc theo chu kỳ: Mùi này phát sinh khi hai hoặc nhiều trừu tượng phụ thuộc lẫn nhau trực tiếp hoặc gián tiếp (tạo ra một khớp nối chặt chẽ giữa các trừu tượng).

Modularization giống như Hub: Mùi này phát sinh khi một sự trừu tượng có sự phụ thuộc (cả đến và đi) với một số lượng lớn các trừu tượng khác.

Phân cấp mùi

Thiếu phân cấp: Mùi này phát sinh khi một đoạn mã sử dụng logic có điều kiện (thường kết hợp với các loại được gắn thẻ của LINE) để quản lý rõ ràng sự thay đổi trong hành vi trong đó hệ thống phân cấp có thể được tạo và sử dụng để đóng gói các biến thể đó.

Phân cấp không cần thiết: Mùi này phát sinh khi toàn bộ hệ thống phân cấp thừa kế là không cần thiết, cho thấy rằng kế thừa đã được áp dụng không cần thiết cho bối cảnh thiết kế cụ thể.

Phân cấp không được bảo vệ: Mùi này phát sinh khi có sự trùng lặp không cần thiết giữa các loại trong một hệ thống phân cấp.

Phân cấp rộng: Mùi này phát sinh khi một hệ thống phân cấp thừa kế là quá rộng quá chỉ ra rằng các loại trung gian có thể bị thiếu.

Phân cấp đầu cơ: Mùi này phát sinh khi một hoặc nhiều loại trong hệ thống phân cấp được cung cấp theo suy đoán (nghĩa là dựa trên nhu cầu tưởng tượng thay vì yêu cầu thực tế).

Phân cấp sâu: Mùi này phát sinh khi một hệ thống phân cấp thừa kế là sâu quá mức.

Phân cấp nổi loạn: Mùi này phát sinh khi một kiểu con từ chối các phương thức được cung cấp bởi (các) siêu kiểu của nó.

Hệ thống phân cấp bị hỏng: Mùi này phát sinh khi một siêu kiểu và phân nhóm của nó về mặt khái niệm không chia sẻ mối quan hệ IS IS-A khác dẫn đến khả năng thay thế bị phá vỡ.

Phân cấp đa đường: Mùi này phát sinh khi một kiểu con kế thừa cả trực tiếp cũng như gián tiếp từ một siêu kiểu dẫn đến các đường dẫn thừa kế không cần thiết trong cấu trúc phân cấp.

Phân cấp theo chu kỳ: Mùi này phát sinh khi một siêu kiểu trong hệ thống phân cấp phụ thuộc vào bất kỳ phân nhóm nào của nó.

Định nghĩa và phân loại ở trên được mô tả trong "Tái cấu trúc cho thiết kế phần mềm có mùi: Quản lý nợ kỹ thuật ". Một số tài nguyên có liên quan hơn có thể được tìm thấy ở đây .

Một mô hình là một ý tưởng về cách giải quyết vấn đề của một số lớp. Một mô hình chống là một ý tưởng về cách không giải quyết nó bởi vì thực hiện ý tưởng đó sẽ dẫn đến thiết kế xấu.

Một ví dụ: một "mẫu" sẽ là sử dụng một hàm để sử dụng lại mã, một "chống mẫu" sẽ là sử dụng bản sao-dán cho cùng. Cả hai đều giải quyết cùng một vấn đề, nhưng sử dụng một hàm thường dẫn đến mã dễ đọc và dễ bảo trì hơn so với sao chép-dán.

Một mô hình chống là một cách không giải quyết vấn đề. Nhưng có nhiều hơn thế: đó cũng là một cách thường xuyên được nhìn thấy trong các nỗ lực để giải quyết vấn đề.

Nếu bạn thực sự muốn nghiên cứu AntiPotypes, hãy lấy cuốn sách AntiPotypes (ISBN-13: 978-0471197133).

Trong đó, họ định nghĩa "Một AntiPotype là một hình thức văn học mô tả một giải pháp thường xảy ra cho một vấn đề tạo ra hậu quả tiêu cực quyết định."

Vì vậy, nếu đó là một thực tiễn lập trình tồi nhưng không phải là một phổ biến giới hạn ở một ứng dụng, một công ty hoặc một lập trình viên, thì nó không đáp ứng phần "Mẫu" trong định nghĩa AntiPotype.

Một cách phổ biến để làm cho một mớ hỗn độn. Ví dụ như lớp thần / bếp (làm mọi thứ) chẳng hạn.

Điều thú vị là một cách nhất định để giải quyết vấn đề có thể vừa là mẫu vừa là mẫu chống. Singleton là ví dụ điển hình của việc này. Nó sẽ xuất hiện trong cả hai bộ văn học.

Một mô hình chống là sự bổ sung của một mẫu thiết kế . Một mô hình chống là một giải pháp mẫu bạn không nên sử dụng trong một tình huống nhất định.

Giống như với một mẫu thiết kế , một mẫu chống cũng là một mẫu và một cách lặp lại để giải quyết một vấn đề nhất định, nhưng theo cách không tối ưu và không hiệu quả.

Ngày nay, các nhà nghiên cứu và thực hành kỹ thuật phần mềm thường sử dụng các thuật ngữ có thể thay thế cho nhau. Tuy nhiên, về mặt khái niệm chúng không giống nhau. Mục nhập chống mẫu của Wikipedia cho biết một mẫu chống khác với thực tiễn xấu hoặc ý tưởng xấu bởi ít nhất hai yếu tố. Một mô hình chống là

"Một quy trình, cấu trúc hoặc mô hình hành động thường được sử dụng mà mặc dù ban đầu dường như là một phản ứng phù hợp và hiệu quả đối với một vấn đề, thường có nhiều hậu quả xấu hơn kết quả có lợi.

Nó chỉ ra rõ ràng rằng một mô hình chống được chọn với niềm tin rằng đó là một giải pháp tốt (như một mô hình) cho vấn đề được trình bày; tuy nhiên, nó mang lại nhiều trách nhiệm hơn lợi ích. Mặt khác, một mùi chỉ đơn giản là một thực tiễn xấu ảnh hưởng tiêu cực đến chất lượng của một hệ thống phần mềm. Ví dụ, Singleton là một lớp chống mẫu và lớp Thần (hoặc Modularization không đủ) là một mùi thiết kế.

Chống mẫu là những cách phổ biến mà mọi người có xu hướng lập trình sai, hoặc ít nhất là cách không tốt.

Bất kỳ mẫu thiết kế nào gây hại nhiều hơn cho môi trường phát triển phần mềm nhất định sẽ được coi là chống mẫu.

Một số chống mẫu là rõ ràng nhưng một số thì không. Ví dụ Singleton, mặc dù nhiều người cho rằng nó là mẫu thiết kế cũ tốt nhưng có những người khác thì không.

Bạn có thể kiểm tra câu hỏi Điều gì là xấu về singletons? để hiểu rõ hơn các ý kiến ​​khác nhau về nó.

Giống như trong Thuật toán, bạn có thể đạt được giải pháp bằng cách sử dụng lực Brute, nhưng bạn phải trả nhiều tiền nếu tình huống trở nên phức tạp.