Bối rối về nguyên tắc trách nhiệm duy nhất trong ví dụ sau

Question

Trong số video sau, tác giả nhận một lớp hiện có và gán Nguyên tắc về trách nhiệm duy nhất cho nó. Anh ấy lấy một Print Class có công việc truy cập dữ liệu, định dạng và in báo cáo. Anh ta phá vỡ từng phương thức thành lớp riêng của mình, vì vậy anh ta tạo ra một lớp DataAccess để xử lý truy cập dữ liệu, anh ta tạo một lớp ReportFormatter để xử lý định dạng của Báo cáo và tạo lớp ReportPrinter để xử lý việc in Báo cáo. Lớp Report ban đầu sau đó được để lại với một phương thức, Print() gọi phương thức lớp của ReportPrinter là Print. DataAccess và ReportFormatter dường như có trách nhiệm, nhưng ReportPrinter dựa trên DataAcess và ReportFormatter, vì vậy điều này không phá vỡ SRP hay tôi hiểu nhầm nó?

Answer 1

Nguyên tắc về trách nhiệm duy nhất cho thấy rằng một lớp nhất định phải có một trách nhiệm duy nhất (hoặc 'lý do thay đổi'). Nó không, trong và của chính nó, chỉ ra rằng trách nhiệm đó là để được hài lòng. Làm như vậy có thể và thường xuyên yêu cầu sự hợp tác của nhiều lớp khác với tư cách cộng tác viên.

Answer 2

SRP không giải quyết các phụ thuộc. Chia lớp học thành các lớp học có trách nhiệm duy nhất sẽ tạo thuận lợi cho việc phá vỡ những phụ thuộc đó sau này. SRP giải quyết một trong hai nguyên tắc được đề cập với nhau: Sự gắn kết và khớp nối. SRP là về sự gắn kết cao, và các phụ thuộc có thể là dấu hiệu của sự ghép nối cao. Thiết kế tốt có độ kết dính cao và khớp nối thấp. Đôi khi hai nguyên tắc này có thể có tỷ lệ cược.

Answer 3

Nếu không xem video, nó có vẻ giống như một thiết kế hợp lý. SRP không bị hỏng, vì các phương thức xử lý truy cập dữ liệu không xuất hiện trong lớp ReportPrinter, chỉ có khái niệm "Tôi có thể gọi một thứ gì đó để lấy dữ liệu tôi muốn".

Bạn có thể đẩy nó thêm một chút và có một lớp điều phối chịu trách nhiệm chỉ để điều phối các hoạt động của lớp truy cập dữ liệu, lớp định dạng và lớp máy in. Bạn cũng có thể sắp xếp các đối tượng theo nhiều cách khác nhau, như việc điều phối viên gửi dữ liệu đến trình định dạng, gửi dữ liệu đến máy in và điều phối viên không (trực tiếp) biết về máy in.

Điều gì đó phải biết về điều phối nỗ lực của các đối tượng tập trung hẹp. Điều đó trở thành trách nhiệm của họ. Bạn có thể biết về ý tưởng hoặc khái niệm về những gì các đối tượng khác sẽ làm, miễn là bạn không biết hoặc quan tâm cách thức hoạt động của. Suy nghĩ về giao diện là "đường nối trách nhiệm" là một khởi đầu tốt.

Nó cũng có thể hữu ích nếu bạn nghĩ về các đối tượng như truyền dữ liệu cho nhau, thay vì "làm" mọi thứ. Vì vậy, ReportFormatter trả về (hoặc chuyển tiếp) một đối tượng mới biểu diễn một báo cáo được định dạng, thay vì (khái niệm) các đối tượng thực hiện trên một báo cáo hiện có.

Answer 4

No. Không phá vỡ SRP.

Giả sử rằng

DataAccess implements IDataAccess  

ReportFormatter implements IReportFormatter 

ReportPrinter implements IReportPrinter 

tổ chức sự kiện dù ReportPrinter relies on DataAccess and ReportFormatter, bất kỳ sự thay đổi trong hợp đồng IDataAccess or IReportFormatter nên được thực hiện bởi DataAccess and ReportFormatter tương ứng. ReportPrinter không lo lắng về những thay đổi trách nhiệm trong các lớp đó.

Bạn có thể có Composition hoặc triển khai mẫu Mediator để cung cấp ghép nối lỏng lẻo giữa ba lớp này và hoàn thành công việc. Giữ coupling cách xa responsibility.