Tôi không thấy hữu ích trong những ngày này để tranh luận về những gì không và không cấu thành một trách nhiệm duy nhất hoặc một lý do duy nhất để thay đổi. Tôi sẽ đề xuất một Nguyên tắc đau buồn tối thiểu ở vị trí của nó:
Nguyên tắc đau buồn tối thiểu: mã nên tìm cách giảm thiểu xác suất yêu cầu thay đổi hoặc tối đa hóa sự dễ dàng thay đổi.
Thế nào Không nên lấy một nhà khoa học tên lửa để tìm hiểu lý do tại sao điều này có thể giúp giảm chi phí bảo trì và hy vọng nó không phải là một cuộc tranh luận bất tận, nhưng nói chung với RẮN, không phải là thứ gì đó để áp dụng một cách mù quáng ở mọi nơi. Đó là một cái gì đó để xem xét trong khi cân bằng sự đánh đổi.
Đối với xác suất yêu cầu thay đổi, điều đó đi xuống với:
- Kiểm tra tốt (độ tin cậy được cải thiện).
- Chỉ liên quan đến mã tối thiểu trần cần thiết để làm một cái gì đó cụ thể (điều này có thể bao gồm giảm các khớp nối hướng tâm).
- Chỉ cần tạo mã badass theo những gì nó làm (xem Nguyên tắc tạo Badass).
Đối với những khó khăn trong việc thực hiện các thay đổi, nó đi lên với các khớp nối hiệu quả. Thử nghiệm giới thiệu khớp nối hiệu quả nhưng nó cải thiện độ tin cậy. Hoàn thành tốt, nó thường làm tốt hơn hại và hoàn toàn được chấp nhận và thúc đẩy bởi Nguyên tắc đau buồn tối thiểu.
Thực hiện nguyên tắc Badass: các lớp được sử dụng ở nhiều nơi sẽ rất tuyệt vời. Họ nên đáng tin cậy, hiệu quả nếu điều đó liên quan đến chất lượng của họ, vv
Và Nguyên tắc Make Badass gắn liền với Nguyên tắc đau buồn tối thiểu, vì những thứ xấu sẽ tìm thấy xác suất yêu cầu thay đổi thấp hơn so với những thứ hút vào những gì chúng làm.
Tôi đã bắt đầu bằng cách chỉ ra nghịch lý được đề cập ở trên, và sau đó chỉ ra rằng SRP phụ thuộc nhiều vào mức độ chi tiết mà bạn muốn xem xét và nếu bạn đưa nó đủ xa, bất kỳ lớp nào có nhiều hơn một thuộc tính hoặc một phương thức đều vi phạm nó
Từ quan điểm SRP, một lớp hầu như không làm gì chắc chắn sẽ chỉ có một lý do (đôi khi bằng không) để thay đổi:
class Float
{
public:
explicit Float(float val);
float get() const;
void set(float new_val);
};
Điều đó thực tế không có lý do để thay đổi! Nó tốt hơn SRP. Đó là ZRP!
Ngoại trừ tôi sẽ đề nghị nó vi phạm trắng trợn Nguyên tắc Make Badass. Nó cũng hoàn toàn vô giá trị. Một cái gì đó rất ít có thể hy vọng là badass. Nó có quá ít thông tin (TLI). Và tự nhiên khi bạn có một thứ gì đó là TLI, nó không thể làm bất cứ điều gì thực sự có ý nghĩa, ngay cả với thông tin được gói gọn, vì vậy nó phải rò rỉ ra thế giới bên ngoài với hy vọng rằng ai đó sẽ thực sự làm điều gì đó có ý nghĩa và xấu xa. Và sự rò rỉ đó là ổn đối với một cái gì đó chỉ nhằm mục đích tổng hợp dữ liệu và không có gì hơn, nhưng ngưỡng đó là sự khác biệt như tôi thấy giữa "dữ liệu" và "đối tượng".
Tất nhiên một cái gì đó là TMI là xấu là tốt. Chúng tôi có thể đặt toàn bộ phần mềm của chúng tôi trong một lớp. Nó thậm chí có thể chỉ có một runphương pháp. Và ai đó thậm chí có thể lập luận rằng bây giờ nó có một lý do rất rộng để thay đổi: "Lớp này sẽ chỉ cần thay đổi nếu phần mềm cần cải tiến." Tôi thật ngớ ngẩn, nhưng tất nhiên chúng ta có thể tưởng tượng tất cả các vấn đề bảo trì với điều đó.
Vì vậy, có một hành động cân bằng như độ chi tiết hoặc độ thô của các đối tượng bạn thiết kế. Tôi thường đánh giá nó bằng bao nhiêu thông tin bạn phải rò rỉ ra thế giới bên ngoài và bao nhiêu chức năng có ý nghĩa mà nó có thể thực hiện. Tôi thường thấy Nguyên tắc Make Badass hữu ích ở đó để tìm sự cân bằng trong khi kết hợp nó với Nguyên tắc đau buồn tối thiểu.