단일 책임 원칙의 단점

Question

나는 여러 권의 책을 읽고 소프트웨어 디자인에 관한 강의를 듣습니다. 하지만 OO 설계에 따른 문제를 해결하는 방법을 모르겠습니다.

여기에 어떤 상황이 있습니다. 간단한 단일 클래스 (ClassA)를 디자인하기 시작합니다. 그런 다음 ClassA는 비슷한 책임으로 자랍니다. Single Responsibility Priciple에 따르면 ClassA에서 ClassB로 로직을 추출합니다. ClassA가 다시 충분히 단순 해집니다. 그러나 ClassA의 책임은 ClassB, 의 책임과 유사 할 수 있으므로 ClassA와 ClassB는 서로를 구성원 필드 또는 협력 속성으로 참조해야합니다. 즉, 클래스의 분리는 또 다른 복잡성을 만듭니다. 이것은 분리 된 클래스 간의 상호 작용입니다. 이후부터 ClassA와 ClassB 각각은 더 복잡한 책임을 가지고 성장할 수도 있습니다 ( ). 일부 클래스 (ClassC 또는 ClassD)는 ClassA 또는 ClassB로부터 분리 될 수 있습니다. 이제 클래스 간의 상호 작용이 훨씬 더 복잡해졌습니다. 각 클래스는 다른 클래스에 대한 참조를 구성원 필드 또는 메서드 매개 변수로 가질 수 있습니다.

단일 클래스가 단순 해짐에 따라 클래스 수가 증가하고 관계의 복잡성 및 클래스 간 상호 작용이 증가합니다.

어떤 경우에는 설계 패턴에 의해 해결 될 수 있습니다. 그러나 많은 경우에 클래스의 분리는 클래스의 관계를 더 복잡하게 만듭니다. 및 기타 클래스에 대한 참조가 너무 많은 클래스를 생성하는 경향이 있습니다. 다른 클래스에 대한 참조가 너무 많은 클래스는 테스트하기가 어렵습니다.

몇 가지 OO 설계 도서를 읽었습니다. 그들 중 대부분은 간단한 수업이 좋은 것이라고 이야기합니다. 그러나 이들 중 누구도 SRP로 인한 클래스 상호 작용의 복잡성에 초점을 맞추지 않습니다.

내가 무엇인가 놓친가요? 이 문제를 어떻게 해결할 수 있습니까?

Answer 1

책임은 변경해야 할 한 가지 이유를 의미합니다.

한 가지 이유 때문에 클래스 A를 변경해야 할 수도 있습니다. 실수로 클래스 A에서 다른 책임의 동작을 변경하는 경우가 있습니다. 클래스 A의 기능 중 하나가 필요하거나 테스트 할 때가 있지만 언젠가는 당신은 클래스 A에없는 별도의 클래스 A를 할 경우 전체 클래스 A를

을 만들, B, C 및 D, 책임 사이의 상호 작용은 여전히 ​​

하려면 존재하지만 클래스 A에 숨겨진 클래스가보다 일관성 있고 상호 작용이 명확 해지면 코드를 유지 관리 할 수 ​​있습니다.

Answer 2

클래스 크기 측면에서 srp에 대해 생각하는 것이 좋지 않다고 생각합니다. 나는 배우와 변화해야 할 이유에 대해 생각해야한다고 생각합니다.

액터는 클래스를 변경하려는 역할입니다. 예를 들어 다음과 같은 클래스가있는 경우 :

class User 
{ 
    public function calculatePay() 
    public function save() 

} 

두 가지 역할이 클래스를 변경하려고합니다. 예를 들어, 회계사는 calculatePay 메소드를 변경하려고하고 DB 관리자는 save() 메소드를 변경하려고합니다. 이 클래스는 두 가지 이유로 변경 될 수 있습니다.

"동일한 이유로 변경되는 항목을 그룹화"하는 측면에서 srp를 생각하는 것이 좋습니다.