Là nguyên tắc trách nhiệm duy nhất áp dụng cho các chức năng?

Theo Robert C. Martin, SRP tuyên bố rằng:

Không bao giờ nên có nhiều hơn một lý do để một lớp thay đổi.

Tuy nhiên, trong cuốn sách Clean Code , chương 3: Hàm, ông cho thấy khối mã sau:

    public Money calculatePay(Employee e) throws InvalidEmployeeType {
        switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
    }

Và sau đó tuyên bố:

Có một số vấn đề với chức năng này. Đầu tiên, nó lớn và khi các loại nhân viên mới được thêm vào, nó sẽ phát triển. Thứ hai, nó rất rõ ràng làm nhiều hơn một điều. Thứ ba, nó vi phạm Nguyên tắc Trách nhiệm Đơn lẻ (SRP) vì có nhiều hơn một lý do để nó thay đổi . [nhấn mạnh của tôi]

Đầu tiên, tôi nghĩ SRP được định nghĩa cho các lớp, nhưng hóa ra nó cũng có thể áp dụng cho các hàm. Thứ hai, làm thế nào mà chức năng này có nhiều hơn một lý do để thay đổi ? Tôi chỉ có thể thấy nó thay đổi vì sự thay đổi của Nhân viên.

Một chi tiết thường bị bỏ qua của Nguyên tắc Trách nhiệm duy nhất là "lý do thay đổi" được nhóm theo các tác nhân trong trường hợp sử dụng (bạn có thể xem giải thích đầy đủ tại đây ).

Vì vậy, trong ví dụ của bạn, calculatePayphương thức sẽ cần được thay đổi bất cứ khi nào cần loại Nhân viên mới. Vì một loại nhân viên có thể không liên quan gì đến người khác, nên sẽ vi phạm nguyên tắc nếu bạn giữ họ cùng nhau, vì sự thay đổi sẽ ảnh hưởng đến các nhóm người dùng khác nhau (hoặc các tác nhân trong trường hợp sử dụng) trong hệ thống.

Bây giờ, về việc liệu nguyên tắc này có áp dụng cho các hàm hay không: Ngay cả khi bạn vi phạm chỉ trong một phương thức, bạn vẫn thay đổi một lớp vì nhiều lý do, vì vậy nó vẫn là vi phạm SRP.

Trên trang 176, Chương 12: Sự xuất hiện, trong phần có tiêu đề Các lớp học và phương pháp tối thiểu, cuốn sách cung cấp phần nào sự điều chỉnh, bằng cách nêu:

Trong nỗ lực làm cho các lớp và phương thức của chúng ta nhỏ đi, chúng ta có thể tạo ra quá nhiều lớp và phương thức nhỏ. Vì vậy, quy tắc này cho thấy rằng chúng tôi cũng giữ chức năng và số lượng lớp của chúng tôi thấp

và

Số lượng cao và phương pháp đôi khi là kết quả của chủ nghĩa giáo điều vô nghĩa.

Rõ ràng, anh ta đang nói về chủ nghĩa giáo điều khi theo SRP để phá vỡ các phương pháp nhỏ vô tội hoàn toàn tốt như calculatePay()trên.

Khi ông Martin áp dụng SRP cho một chức năng, ông hoàn toàn mở rộng định nghĩa về SRP của mình. Vì SRP là một từ ngữ dành riêng cho OO của một nguyên tắc chung và vì đó là một ý tưởng tốt khi áp dụng cho các chức năng, tôi không thấy có vấn đề gì với điều đó (mặc dù nó có thể tốt nếu anh ấy đưa nó vào trong Định nghĩa).

Tôi cũng không thấy nhiều lý do để thay đổi và tôi không tin rằng việc nghĩ về SRP về "trách nhiệm" hay "lý do để thay đổi" là hữu ích. Về cơ bản những gì SRP đang nhận được là các thực thể phần mềm (chức năng, lớp, v.v.) nên làm một việc và làm tốt điều đó.

Nếu bạn nhìn vào định nghĩa của tôi, nó không hề mơ hồ so với cách diễn đạt thông thường của SRP. Vấn đề với các định nghĩa thông thường về SRP không phải là chúng quá mơ hồ, mà là chúng cố gắng quá cụ thể về một điều gì đó về cơ bản là mơ hồ.

Nếu bạn nhìn vào những gì calculatePaylàm, nó rõ ràng đang làm một điều duy nhất: công văn dựa trên loại. Do Java có các cách thức thực hiện công văn dựa trên kiểu, calculatePaykhông phù hợp và không thành ngữ, do đó, nó nên được viết lại, nhưng không phải vì các lý do đã nêu.

Bạn nói đúng @Enrique. Bất kể đó là hàm hay phương thức của lớp, SRP có nghĩa là trong khối mã đó bạn chỉ làm một việc.

Tuyên bố 'lý do để thay đổi' đôi khi hơi sai lệch, nhưng nếu bạn thay đổi calculateSalariedPayhoặc calculateHourlyPayhoặc enum của Employee.typebạn phải thay đổi phương pháp này.

Trong ví dụ của bạn, hàm:

• kiểm tra loại nhân viên
• gọi một hàm khác tính tiền theo loại

Theo tôi, đó không phải là vi phạm SRP trực tiếp, vì các trường hợp chuyển đổi và các cuộc gọi không thể được viết ngắn hơn, nếu bạn nghĩ về Nhân viên và các phương thức đã tồn tại. Dù sao, đó là một vi phạm nguyên tắc đóng (OCP) rõ ràng vì bạn phải nối các câu lệnh 'trường hợp' nếu bạn thêm các loại nhân viên, do đó, đó là một cách thực hiện tồi: tái cấu trúc nó.

Chúng tôi không biết nên tính toán 'Tiền' như thế nào, nhưng cách dễ nhất là có Employeegiao diện và một số triển khai cụ thể bằng getMoneycác phương thức. Trong trường hợp đó, toàn bộ chức năng là không cần thiết.

Nếu tính toán phức tạp hơn, người ta có thể sử dụng mẫu khách truy cập không phải là 100% SRP nhưng đó là OCP nhiều hơn trường hợp chuyển đổi.