다음 예에서 단일 책임 원칙에 대해 혼란스러워합니다

Question

다음에서 동영상, 저자는 기존 클래스를 수업하고 단일 책임 원칙을 할당합니다. 그는 데이터에 액세스, 서식 및 보고서 인쇄 작업을하는 인쇄 수업을받습니다. 그는 각 방법을 자체 클래스로 나누기 때문에 데이터 액세스를 처리하기 위해 DataAccess 클래스를 작성하고 보고서의 형식을 처리하기 위해 ReportFormatter 클래스를 작성하고 보고서의 인쇄를 처리하기 위해 ReportPrinter 클래스를 만듭니다. 그런 다음 원래 보고서 클래스에는 reportPrinter의 클래스 메소드 인쇄를 호출하는 하나의 메소드 인 print ()가 남아 있습니다. DataAccess와 ReportFormatter는 책임이있는 것으로 보이지만 ReportPrinter는 DataAncess 및 ReportFormatter에 의존합니다. 따라서 SRP를 깨뜨리지 않거나 오해하지 않습니까?

Answer 1

단일 책임 원칙은 주어진 클래스가 단일 책임 (또는 '변경 이유')을 가져야 함을 나타냅니다. 그것은 그 자체로 그 책임이 어떻게 만족 될 것인지를 나타내지 않습니다. 그렇게하는 것은 종종 공동 작업자로서 여러 다른 클래스의 협력을 요구할 수 있습니다.

Answer 2

비디오를 보지 않으면 합리적인 디자인처럼 들립니다. 데이터 액세스를 다루는 방법이 ReportPrinter 클래스에 나타나지 않기 때문에 SRP는 깨지지 않았습니다. "원하는 데이터를 얻기 위해 무언가를 호출 할 수 있다는 개념"만 있습니다.

조금 더 나아가고 데이터 액세스 클래스, Formatter 클래스 및 프린터 클래스의 활동을 조정하는 코디네이터 클래스를 담당 할 수 있습니다. 코디네이터가 프린터로 보내는 Formatter로 데이터를 보내는 등 다양한 방식으로 객체를 배열 할 수 있으며 코디네이터는 프린터에 대해 (직접) 알지 못합니다.

좁게 초점을 맞춘 물체의 노력을 조정하는 것에 대해 무언가를 알아야합니다. 그것은 그들의 책임이됩니다. 당신이 알지 못하거나 돌보는 한 다른 대상이 할 일에 대한 아이디어 나 개념에 대해 아는 것은 괜찮습니다. 어떻게 그들은 그것을합니다. 인터페이스를 "책임의 이음새"라고 생각하는 것은 좋은 시작입니다.

객체를 "행동"하는 대신 데이터를 서로 전달하는 것으로 생각하면 도움이 될 수 있습니다. 따라서 ReportFormatter는 기존 보고서에서 개체를 수행하는 것이 아니라 형식의 보고서를 나타내는 새로운 개체를 반환 (또는 앞으로).

Answer 3

SRP는 종속성을 다루지 않습니다. 클래스를 단일 책임 수업으로 나누면 나중에 이러한 종속성을 깨뜨릴 수 있습니다. SRP는 함께 언급 된 두 가지 원칙 중 하나 인 응집력과 커플 링을 다룹니다. SRP는 높은 응집력에 관한 것이며 종속성은 높은 커플 링을 나타낼 수 있습니다. 좋은 디자인은 응집력이 높고 커플 링이 낮습니다. 때때로이 두 원칙은 상충 될 수 있습니다.

Answer 4

아니요. SRP를 깨뜨리지 않습니다.

그것을 가정합니다

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

그래도 이벤트 ReportPrinter relies on DataAccess and ReportFormatter , 계약의 변경 IDataAccess or IReportFormatter 구현해야합니다 DataAccess and ReportFormatter 각기. ReportPrinter 해당 수업의 책임 변경에 대해 걱정하지 않습니다.

당신은 가질 수 있습니다 Composition 또는 구현 중재인 이 세 클래스 사이에 느슨한 커플 링을 제공하고 작업을 완료하는 패턴. 유지하다 coupling 멀리 떨어져 있습니다 responsibility.