기본 클래스는 많은 보호 된 메서드를 정의합니다. 좋은 OOP 디자인입니까?

Question

많은 보호 된 메소드을 정의한 기본 클래스를 작성했습니다. 이러한 메서드는 하위 클래스에서 호출됩니다. 메소드는 해당 하위 클래스의 기본 작업을 정의합니다.

class Base{ 
    protected void foo(){} 
    protected void bar(){} 
} 

class Sub1 extends Base{//The sub class only needs Base.foo() 
    public void po(){ 
    ... 
    foo(); 
    ... 
    } 
} 

class Sub2 extends Base{//The sub class only needs Base.bar() 
    public void ko(){ 
    ... 
    bar(); 
    ... 
    } 
} 

class Sub3 extends Base{//The sub class needs both Base.bar() and Base.foo() 
    public void lo(){ 
    ... 
    bar(); 
    ... 
    foo(); 
    } 
} 

그것은 좋은 OOP 설계 인 경우 난 그냥 궁금 : 예를 들어 ? 출처를 읽으십시오. Sub1은 Base.bar()을 전혀 필요로하지 않습니다. Sub2은 Base.foo()을 전혀 필요로하지 않습니다. 그것은 내가 생각하기에 일종의 중복이다. 그러나 나는 더 나은 해결책을 모른다, 누군가는 약간 통보를 줄 수 있 었는가? 감사!

Answer 1

일반적으로 이러한 종류의 개체 종속성은 디자인에서 피해야합니다. foo는()와 파생 클래스에서 변경되지 않는 바()의 기능, 당신은 대신 그 일을 외부 클래스에 넣어 사용할 수있는 경우 :

class Base{ 

} 

class Helper1 { 
    public void foo(){} 
} 

class Helper2 { 
    public void bar(){} 
} 

class Sub1 extends Base{ 
    private Helper1 a = new Helper1(); 
    private Helper2 b = new Helper2(); 

    public void po(){ 
    ... 
    a.foo(); 
    ... 
    b.bar(); 
    } 
} 

class Sub2 extends Base{ 
    private Helper2 b = new Helper2(); 

    public void ko(){ 
    ... 
    b.bar(); 
    ... 
    } 
} 

이 foo는 & 바 예는 보이지 않는다 잘. 당신의 문제는 객체에 대한 책임감 또는 상속의 오용 일 수 있습니다. 실제 코드를 게시하면 더 나은 답변을 작성하는 데 도움이됩니다.

Answer 2

사과,하지만 당신은 잘못된 생각을하고 있습니다. 문제는 "sub2가 기초를 상속해야 하는가, 그 방법이 필요하지 않다"이다.

질문은 "개구리가 동물인가?"와 같은 질문은 "sub2 a Base"여야 하는가? 예, 개구리는 동물을 물려받을 수 있지만 개구리는 포유류를 상속해서는 안됩니다.

sub02 이 인 경우 올바르게 작동 할 수 있습니다. 기본 기능이 유용 할 수있는 컬렉션 일 경우 문제가 있습니다.

Answer 3

내 생각

1 처음으로 당신의 디자인은, 난 당신이 만드는 객체가 서로 다른 서브 클래스에서 Helper1, Helper2을 것을 분명히 알 수있는 실행 종속 주입의 원리를 따라하려고도 코드를 복제 할 수있는 경우 .

2 helper1과 helper 2의 다른 인스턴스가 필요하지 않거나 필요한 경우 Virtual을 가상으로 만들 수 있으므로 기본 클래스의 속성으로 Helper1 및 Helper 2 만들기를 제안합니다.

3 구현에 직접 작성하고 있으며 클라이언트 코드는 인터페이스를 사용하는 구체적인 클래스에 따라 달라 지므로 클래스를보다 쉽게 ​​테스트 할 수 있습니다.

4- 황금률은 다음과 같습니다. 현재 다루고있는 문제가 그리 복잡하지 않고 가까운 미래에 변경하려는 이유가 보이지 않는 경우 수행하지 말라. 너의 인생은 복잡하다.

모든 좋은 oop 프로그래밍이 좋지만 ABSTRACTION을 사용하기 위해 더 간단한 방법을 구현하는 것보다 더 쉽고 간단한 솔루션을 보게되면 복잡성의 댓가를 지불하게됩니다.

또 하나의 중요한 규칙 : 올바른 디자인에 맞춰 디자인을 변경하지 않고 클래스 디자인을 테스트 해보십시오.

Answer 4

나는 Interface segregation Principle의 솔리드 규칙 중 하나를 보았습니다.

하위 클래스에 모든 기본 클래스 함수가 ​​필요하지 않은 경우 기본 클래스를 더 구체적인 기본 클래스 또는 인터페이스로 분할 할 수 있습니다.