Làm rõ nguyên tắc trách nhiệm duy nhất

Nguyên tắc trách nhiệm duy nhất nói rằng một lớp nên làm một và chỉ một việc. Một số trường hợp được cắt khá rõ ràng. Tuy nhiên, những người khác thì khó khăn vì những gì trông giống như "một thứ" khi được xem ở một mức độ trừu tượng nhất định có thể là nhiều thứ khi được xem ở mức thấp hơn. Tôi cũng sợ rằng nếu Nguyên tắc Trách nhiệm Đơn lẻ được tôn vinh ở các cấp thấp hơn, mã ravioli phân tách quá mức, trong đó nhiều dòng được dành để tạo ra các lớp nhỏ cho mọi thứ và xử lý thông tin xung quanh hơn là thực sự giải quyết vấn đề trong tay, có thể dẫn đến.

Làm thế nào bạn sẽ mô tả "một điều" có nghĩa là gì? Một số dấu hiệu cụ thể mà một lớp thực sự làm nhiều hơn "một điều" là gì?

Tôi thực sự thích cách Robert C. Martin (chú Bob) khôi phục Nguyên tắc Trách nhiệm duy nhất (được liên kết với PDF) :

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

Nó khác biệt một cách tinh tế so với định nghĩa "chỉ nên làm một điều" truyền thống và tôi thích điều này bởi vì nó buộc bạn phải thay đổi cách bạn nghĩ về lớp học của mình. Thay vì suy nghĩ về "điều này có làm một việc không?", Thay vào đó bạn nghĩ về những gì có thể thay đổi và những thay đổi đó ảnh hưởng đến lớp học của bạn như thế nào. Vì vậy, ví dụ, nếu cơ sở dữ liệu thay đổi, lớp của bạn cần phải thay đổi? Còn nếu thiết bị đầu ra thay đổi (ví dụ như màn hình, hoặc thiết bị di động hoặc máy in) thì sao? Nếu lớp của bạn cần thay đổi vì những thay đổi từ nhiều hướng khác, thì đó là dấu hiệu cho thấy lớp của bạn có quá nhiều trách nhiệm.

Trong bài viết được liên kết, chú Bob kết luận:

SRP là một trong những nguyên tắc đơn giản nhất và là một trong những nguyên tắc khó nhất để có được quyền. Các trách nhiệm liên kết là điều mà chúng tôi làm một cách tự nhiên. Tìm kiếm và tách biệt các trách nhiệm đó với nhau là phần lớn những gì thiết kế phần mềm thực sự hướng tới.

Tôi tiếp tục tự hỏi SRP đang cố gắng giải quyết vấn đề gì? Khi nào SRP giúp tôi? Đây là những gì tôi nghĩ ra:

Bạn nên cấu trúc lại trách nhiệm / chức năng của một lớp khi:

1) Bạn đã sao chép chức năng (DRY)

2) Bạn thấy rằng mã của bạn cần một mức độ trừu tượng khác để giúp bạn hiểu về nó (KISS)

3) Bạn thấy rằng các phần chức năng được các chuyên gia tên miền của bạn hiểu là tách biệt với một thành phần khác (Ngôn ngữ Ubiquitous)

Bạn KHÔNG NÊN tái cấu trúc trách nhiệm ra khỏi một lớp khi:

1) Không có bất kỳ chức năng trùng lặp.

2) Các chức năng không có ý nghĩa bên ngoài bối cảnh của lớp học của bạn. Nói cách khác, lớp của bạn cung cấp một bối cảnh để dễ hiểu chức năng hơn.

3) Các chuyên gia tên miền của bạn không có khái niệm về trách nhiệm đó.

Tôi nhận thấy rằng nếu SRP được áp dụng rộng rãi, chúng ta trao đổi một loại phức tạp (cố gắng tạo ra đầu hoặc đuôi của một lớp với quá nhiều thứ đang diễn ra bên trong) với một loại khác (cố gắng giữ tất cả các cộng tác viên / cấp độ của trừu tượng hóa thẳng để tìm ra những gì các lớp này thực sự làm).

Khi nghi ngờ, hãy để nó ra! Bạn luôn có thể cấu trúc lại sau này, khi có một trường hợp rõ ràng cho nó.

Bạn nghĩ sao?

Tôi không biết nếu có một thang đo khách quan cho nó nhưng những gì sẽ cho đi điều này sẽ là các phương pháp - không quá nhiều trong số chúng mà là sự đa dạng của chức năng của chúng. Tôi đồng ý bạn có thể phân tách quá xa nhưng tôi sẽ không tuân theo bất kỳ quy tắc cứng và nhanh nào về nó.

Câu trả lời nằm trong định nghĩa

Những gì bạn xác định trách nhiệm là, cuối cùng cung cấp cho bạn ranh giới.

Thí dụ:

Tôi có một thành phần có trách nhiệm hiển thị hóa đơn -> trong trường hợp này, nếu tôi bắt đầu thêm bất cứ thứ gì nữa thì tôi sẽ phá vỡ nguyên tắc.

Mặt khác, nếu tôi nói trách nhiệm xử lý hóa đơn -> thêm nhiều chức năng nhỏ hơn (ví dụ như in Hóa đơn , cập nhật Hóa đơn ) thì tất cả đều nằm trong ranh giới đó.

Tuy nhiên, nếu mô-đun đó bắt đầu xử lý bất kỳ chức năng nào bên ngoài hóa đơn , thì nó sẽ nằm ngoài ranh giới đó.

Tôi luôn xem nó ở hai cấp độ:

• Tôi chắc chắn rằng phương pháp của tôi chỉ làm một việc và làm tốt
• Tôi thấy một lớp là một nhóm logic (OO) hợp lý của các phương thức đó thể hiện tốt một điều

Vì vậy, một cái gì đó giống như một đối tượng miền được gọi là Dog:

Doglà lớp học của tôi nhưng Chó có thể làm nhiều việc! Tôi có thể có các phương thức như walk(), run()và bite(DotNetDeveloper spawnOfBill)(xin lỗi không thể cưỡng lại; p).

Nếu Dogtrở nên khó sử dụng thì tôi nghĩ về cách các nhóm phương thức đó có thể được mô hình hóa cùng nhau trong một lớp khác, chẳng hạn như một Movementlớp, có thể chứa các phương thức của tôi walk()và run().

Không có quy tắc cứng và nhanh, thiết kế OO của bạn sẽ phát triển theo thời gian. Tôi cố gắng tìm kiếm một giao diện / API công khai rõ ràng cũng như các phương pháp đơn giản thực hiện tốt một việc và một điều.

Tôi nhìn vào nó nhiều hơn dọc theo dòng của một lớp chỉ nên đại diện cho một điều. Để chiếm đoạt @ dụ Karianna, tôi có tôi Doglớp, trong đó có phương pháp walk(), run()và bark(). Tôi sẽ không để thêm phương pháp meaow(), squeak(), slither()hoặc fly()vì những người không phải những điều mà con chó làm. Chúng là những thứ mà các động vật khác làm, và những động vật khác sẽ có lớp riêng để đại diện cho chúng.

(BTW, nếu con chó của bạn không bay, sau đó bạn nên có lẽ dừng lại ném anh ta ra khỏi cửa sổ).

Một lớp nên làm một việc khi được xem ở mức độ trừu tượng của chính nó. Nó chắc chắn sẽ làm nhiều việc ở mức độ trừu tượng hơn. Đây là cách các lớp hoạt động để làm cho các chương trình dễ bảo trì hơn: chúng ẩn các chi tiết triển khai nếu bạn không cần kiểm tra chúng chặt chẽ.

Tôi sử dụng tên lớp như một bài kiểm tra cho việc này. Nếu tôi không thể đặt cho một lớp một tên mô tả khá ngắn hoặc nếu tên đó có một từ như "Và" trong đó, có lẽ tôi đã vi phạm Nguyên tắc Trách nhiệm duy nhất.

Theo kinh nghiệm của tôi, việc giữ nguyên tắc này ở cấp thấp sẽ dễ dàng hơn, nơi mọi thứ cụ thể hơn.

Đó là về việc có một rô-bốt độc đáo .

Mỗi lớp nên được nối lại bằng một tên vai trò. Trên thực tế, một vai trò là một (bộ) động từ được liên kết với một bối cảnh.

Ví dụ :

Tệp cung cấp quyền truy cập của tệp. Trình quản lý tệp quản lý các đối tượng tệp.

Tài nguyên giữ dữ liệu cho một tài nguyên từ Tệp. ResourceManager giữ và cung cấp tất cả Tài nguyên.

Ở đây bạn có thể thấy rằng một số động từ như "Manage" ngụ ý một tập hợp các động từ khác. Động từ một mình được coi là chức năng tốt hơn so với các lớp, hầu hết thời gian. Nếu động từ ngụ ý quá nhiều hành động có bối cảnh chung của riêng chúng, thì nó phải là một lớp trong chính nó.

Vì vậy, ý tưởng chỉ là để cho bạn có một ý tưởng đơn giản về lớp học bằng cách xác định một vai trò duy nhất, đó có thể là liên kết của một số vai trò phụ (được thực hiện bởi các đối tượng thành viên hoặc các đối tượng khác).

Tôi thường xây dựng các lớp Manager có nhiều lớp khác nhau trong đó. Giống như một Nhà máy, một Cơ quan đăng ký, v.v ... Xem một lớp Người quản lý như một loại trưởng nhóm, một người chỉ huy dàn nhạc hướng dẫn các dân tộc khác làm việc cùng nhau để đạt được một ý tưởng cấp cao. Anh ta có một vai trò, nhưng ngụ ý làm việc với các vai trò độc đáo khác bên trong. Bạn cũng có thể thấy nó giống như cách một công ty được tổ chức: một CEO không phải là một người làm việc hiệu quả ở mức năng suất thuần túy, nhưng nếu anh ta không ở đó, thì không có gì có thể làm việc chính xác với nhau. Đó là vai trò của anh ấy.

Khi bạn thiết kế, xác định vai trò duy nhất. Và đối với mỗi vai trò, một lần nữa hãy xem liệu nó có thể bị cắt trong một số vai trò khác không. Bằng cách đó, nếu bạn cần mô phỏng thay đổi cách Trình quản lý của bạn xây dựng các đối tượng, chỉ cần thay đổi Nhà máy và yên tâm.

SRP không chỉ là về việc phân chia các lớp, mà còn về chức năng ủy nhiệm.

Trong ví dụ Dog được sử dụng ở trên, không sử dụng SRP làm lý do để có 3 lớp riêng biệt như DogBarker, DogWalker, v.v (độ gắn kết thấp). Thay vào đó, hãy nhìn vào việc thực hiện các phương thức của một lớp và quyết định xem chúng có "biết quá nhiều" không. Bạn vẫn có thể có dog.walk (), nhưng có lẽ phương thức walk () nên ủy thác cho một lớp khác các chi tiết về cách đi bộ được thực hiện.

Thực tế, chúng tôi đang cho phép lớp Dog có một lý do để thay đổi: bởi vì Chó thay đổi. Tất nhiên, kết hợp điều này với các nguyên tắc RẮN khác, bạn sẽ mở rộng Dog cho chức năng mới thay vì thay đổi Dog (mở / đóng). Và bạn sẽ tiêm các phụ thuộc của bạn như IMove và IEat. Và tất nhiên bạn sẽ thực hiện các giao diện riêng biệt này (phân tách giao diện). Chó sẽ chỉ thay đổi nếu chúng tôi tìm thấy một lỗi hoặc nếu Chó thay đổi căn bản (Liskov Sub, không mở rộng và sau đó xóa hành vi).

Hiệu quả ròng của RẮN là chúng ta có thể viết mã mới thường xuyên hơn chúng ta phải sửa đổi mã hiện có và đó là một chiến thắng lớn.

Tất cả phụ thuộc vào định nghĩa trách nhiệm và cách định nghĩa đó sẽ ảnh hưởng đến việc bảo trì mã của bạn. Tất cả mọi thứ tập trung vào một điều và đó là cách thiết kế của bạn sẽ giúp bạn trong việc duy trì mã của bạn.

Và Giống như ai đó đã nói "Đi bộ trên nước và thiết kế phần mềm từ các thông số kỹ thuật cụ thể là dễ dàng, miễn là cả hai đều bị đóng băng".

Vì vậy, nếu chúng ta xác định trách nhiệm theo cách cụ thể hơn, thì chúng ta không cần phải thay đổi nó.

Đôi khi trách nhiệm sẽ rõ ràng rõ ràng, nhưng đôi khi nó có thể tinh tế và chúng ta cần quyết định một cách thận trọng.

Giả sử, chúng ta thêm một trách nhiệm khác vào lớp Dog có tên là CatchThief (). Bây giờ nó có thể dẫn đến một trách nhiệm khác. Ngày mai, nếu cách Dog bắt kẻ trộm phải được thay đổi bởi Police Dept, thì lớp Dog sẽ phải được thay đổi. Sẽ tốt hơn nếu tạo một lớp con khác trong trường hợp này và đặt tên là ThiefCathcerDog. Nhưng ở một góc nhìn khác, nếu chúng tôi chắc chắn rằng nó sẽ không thay đổi trong bất kỳ trường hợp nào, hoặc cách thức bắtThief đã phụ thuộc vào một số tham số bên ngoài, thì hoàn toàn ổn khi có trách nhiệm này. Nếu trách nhiệm không quá kỳ lạ thì chúng ta phải quyết định một cách thận trọng dựa trên trường hợp sử dụng.

"Một lý do để thay đổi" phụ thuộc vào người đang sử dụng hệ thống. Hãy chắc chắn rằng bạn có các trường hợp sử dụng cho từng tác nhân và lập danh sách các thay đổi có khả năng nhất, cho mỗi trường hợp thay đổi có thể xảy ra, đảm bảo chỉ có một lớp sẽ bị ảnh hưởng bởi thay đổi đó. Nếu bạn đang thêm một trường hợp sử dụng hoàn toàn mới, hãy đảm bảo bạn chỉ cần mở rộng một lớp để làm như vậy.