구체적인 방법을 재정의하는 것이 코드 냄새입니까?

구체적인 방법을 재정의하는 것이 코드 냄새라는 것이 사실입니까? 구체적인 방법을 재정의해야한다고 생각하기 때문에 :

public class A{
    public void a(){
    }
}

public class B extends A{
    @Override
    public void a(){
    }
}

그것은 다음과 같이 다시 쓸 수 있습니다

public interface A{
    public void a();
}

public class ConcreteA implements A{
    public void a();
}

public class B implements A{
    public void a(){
    }
}

B가 A에서 a ()를 재사용하려면 다음과 같이 다시 작성할 수 있습니다.

public class B implements A{
    public ConcreteA concreteA;
    public void a(){
        concreteA.a();
    }
}

메소드를 재정의하기 위해 상속이 필요하지 않은 것은 사실입니까?

아니요, 코드 냄새가 아닙니다.

• 클래스가 최종 클래스가 아닌 경우 서브 클래스가 될 수 있습니다.
• 메소드가 최종이 아닌 경우 대체 할 수 있습니다.

서브 클래 싱이 적절한 지, 그리고 어떤 메소드를 오버라이드 할 수 있는지주의 깊게 고려해야하는 것은 각 클래스의 책임 내에 있습니다 .

클래스는 자체 또는 임의의 메소드를 최종으로 정의하거나 서브 클래스 화 방법 및 위치에 제한 사항 (가시성 수정 자, 사용 가능한 생성자)을 둘 수 있습니다.

메소드를 대체하는 일반적인 경우 는 서브 클래스에서 (특히 인터페이스에 기본 메소드가 출현 한 Java 8에서) 사용자 정의되거나 최적화 될 수있는 기본 클래스 의 기본 구현 입니다.

class A {
    public String getDescription(Element e) {
        // return default description for element
    }
}

class B extends A {
    public String getDescription(Element e) {
        // return customized description for element
    }
}

비헤이비어 재정의 의 대안 은 비헤이비어가 인터페이스로 추상화되고 클래스에서 구현을 설정할 수있는 전략 패턴 입니다.

interface DescriptionProvider {
    String getDescription(Element e);
}

class A {
    private DescriptionProvider provider=new DefaultDescriptionProvider();

    public final String getDescription(Element e) {
       return provider.getDescription(e);
    }

    public final void setDescriptionProvider(@NotNull DescriptionProvider provider) {
        this.provider=provider;
    }
}

class B extends A {
    public B() {
        setDescriptionProvider(new CustomDescriptionProvider());
    }
}

구체적인 방법을 재정의하는 것이 코드 냄새라는 것이 사실입니까?

일반적으로 구체적인 방법을 재정의하는 것은 코드 냄새입니다.

기본 메소드에는 개발자가 일반적으로 존중하는 동작이 연관되어 있으므로 변경하면 구현이 다른 경우 버그가 발생합니다. 더 나쁜 점은 동작이 변경되면 이전에 올바른 구현으로 인해 문제가 악화 될 수 있다는 것입니다. 그리고 일반적 으로 사소한 구체적인 방법으로 Liskov 대체 원칙 을 존중하는 것은 상당히 어렵습니다 .

이제는 이것이 가능하고 좋은 경우가 있습니다. 반 사소한 방법은 다소 안전하게 재정의 될 수 있습니다. 오버라이드 (over-ridden)되도록 의도 된 "세인 한 디폴트"종류의 행동으로 만 존재하는 기본 메소드는 잘 사용됩니다.

따라서 이것은 나에게 냄새처럼 보입니다. 때로는 좋은, 보통 나쁜 경우, 확인하기 위해 살펴보십시오.

구체적인 방법을 재정의해야하는 경우 [...]로 다시 쓸 수 있습니다.

그런 식으로 다시 쓸 수 있다면 두 클래스를 모두 제어 할 수 있다는 의미입니다. 그러나 클래스 A가 이런 식으로 파생되도록 설계했는지 여부를 알 수 있으며 그렇게하면 코드 냄새가 아닙니다.

반면에 기본 클래스를 제어 할 수없는 경우 다시 작성할 수 없습니다. 따라서 클래스는 이런 식으로 파생되도록 설계되었습니다.이 경우 코드 냄새가 아니거나 그렇지 않은 경우 두 가지 옵션이 있습니다. 다른 솔루션을 찾거나 어쨌든 계속 진행하십시오. 작업 순도는 디자인 순도보다 우선합니다.

먼저,이 질문은 특정 타이핑 시스템 에서만 적용 가능 하다는 점을 지적하겠습니다 . 예를 들어,의 구조 입력 및 오리 타이핑 시스템 - 클래스는 단순히 가진 같은 이름 및있는 방법 서명 할 뜻 클래스 것은이었다 호환 입력 (오리 입력의 경우, 특정 방법에 대해 적어도).

이것은 Java, C ++ 등과 같은 정적으로 유형이 지정된 언어 의 영역과는 매우 다릅니다 . Java 및 C ++뿐만 아니라 C # 및 기타에서도 사용되는 강력한 유형 지정 의 특성입니다 .

난 당신이 방법을 명시해야 자바 배경에서오고있어 추측하고 마지막으로 표시된 경우 생성 계약 디자이너가 그들을 위해 의도 하지 오버라이드 (override) 할 수 있습니다. 그러나 C #과 같은 언어에서는 그 반대가 기본값입니다. 방법은 (어떤 장식없이, 특별한 키워드) "하는 봉인 (C 번호의 버전을" final), 그리고해야 명시 적으로 선언 virtual이러한 경우 허용 오버라이드 (override) 할 수 있습니다.

API 또는 라이브러리 가 재정의 가능한 구체적인 메소드를 사용하여 이러한 언어로 디자인 된 경우 ( 어떤 경우에는) 재정의되는 것이 합리적이어야합니다. 따라서 봉인되지 않은 / 가상 / final구체적 이지 않은 방법 을 재정의하는 것은 코드 냄새가 아닙니다 .     _{(물론 이것은 API 디자이너가 규칙을 따르고 있으며 virtual(C #)으로 표시하거나 final(Java)로 설계하고있는 적절한 방법을 표시한다고 가정합니다.)}

참조

• 구조형 시스템
• 오리 타이핑
• 정적 타이핑
• 강력한 타이핑
• Liskov 대체 원리

예, 슈퍼 안티 패턴 을 호출 할 수 있기 때문 입니다. 또한 메소드의 초기 목적을 변경하고 부작용 (=> 버그)을 도입하며 테스트를 실패하게 할 수 있습니다. 단위 테스트가 빨간색 (실패) 인 클래스를 사용 하시겠습니까? 나는하지 않습니다.

나는 초기 코드 냄새가 방법이 아니 abstract거나 때라고 말함으로써 더 나아갈 것입니다 final. 생성 된 엔터티의 동작을 재정의 (재정의) 할 수 있기 때문에 (이 동작은 손실되거나 변경 될 수 있음) 로 abstract와 final의도는 명백하다 :

• 초록 : 행동을 제공 해야합니다
• 결선 : 행동을 수정할 수 없습니다

기존 클래스에 동작을 추가하는 가장 안전한 방법은 마지막 예제에서 보여주는 것입니다 : 데코레이터 패턴 사용.

public interface A{
    void a();
}

public final class ConcreteA implements A{
    public void a() {
        ...
    }
}

public final class B implements A{
    private final ConcreteA concreteA;
    public void a(){
        //Additionnal behaviour
        concreteA.a();
    }
}