“상속성 구성”이“건조한 원칙”을 위반하고 있습니까?

예를 들어, 다른 클래스를 확장 할 클래스가 있다고 가정합니다.

public class LoginPage {
    public String userId;
    public String session;
    public boolean checkSessionValid() {
    }
}

일부 서브 클래스 :

public class HomePage extends LoginPage {

}

public class EditInfoPage extends LoginPage {

}

사실, 서브 클래스에는 재정의 할 메소드가 없으며 일반적인 방법으로 HomePage에 액세스하지 않습니다.

for (int i = 0; i < loginPages.length; i++) {
    loginPages[i].doSomething();
}

로그인 페이지를 재사용하고 싶습니다. 그러나 https://stackoverflow.com/a/53354 에 따르면 LoginPage 인터페이스가 필요하지 않으므로 여기에서 작성을 선호해야하므로 상속을 사용하지 않습니다.

public class HomePage {
    public LoginPage loginPage;
}

public class EditInfoPage {
    public LoginPage loginPage;
}

그러나 문제는 새 버전의 코드에서 발생합니다.

public LoginPage loginPage;

새 클래스가 추가되면 복제됩니다. LoginPage에 setter 및 getter가 필요한 경우 더 많은 코드를 복사해야합니다.

public LoginPage loginPage;

private LoginPage getLoginPage() {
    return this.loginPage;
}
private void setLoginPage(LoginPage loginPage) {
    this.loginPage = loginPage;
}

제 질문은 "상속성 구성"이 "건조한 원칙"을 위반하는 것입니까?

당신은 반복되는 것이 걱정 되길 기다립니다

public LoginPage loginPage;

두 곳에서 DRY를 위반합니까? 그 논리에 의해

int x;

이제 전체 코드베이스에서 하나의 객체에만 존재할 수 있습니다. 블리.

DRY는 명심해야 할 것이지만 계속하십시오. 게다가

... extends LoginPage

DRY에 대한 항문조차도 당신의 대안으로 복제되고 있습니다.

유효한 DRY 문제는 여러 장소에서 정의 된 여러 장소에서 필요한 동일한 행동에 중점을 두어이 행동을 변경해야 할 경우 여러 장소를 변경해야합니다. 한 곳에서 결정을 내리면 한 곳에서만 변경하면됩니다. 하나의 객체 만이 LoginPage에 대한 참조를 보유 할 수있는 것은 아닙니다.

DRY는 맹목적으로 따라 가지 않아야합니다. 복사 및 붙여 넣기가 좋은 방법이나 클래스 이름을 생각하는 것보다 쉬워서 복제하는 경우 아마도 잘못된 것입니다.

그러나 다른 장소에 다른 책임이 있고 독립적으로 변경해야 할 가능성이 있기 때문에 같은 장소에 동일한 코드를 넣고 싶다면 DRY 시행을 완화하고 동일한 행동이 다른 정체성을 갖도록하는 것이 현명 할 것입니다 . 마법의 숫자를 금지하는 것과 같은 생각입니다.

DRY는 코드의 모양에 관한 것이 아닙니다. 마음이없는 반복으로 아이디어의 세부 사항을 확산시키지 않는 것이 중요합니다. 무의미한 반복은 사물이 실제로 나쁜 방향으로 향하고 있다는 관습이라는 것을 스스로에게 말하려고 할 때입니다.

당신이 정말로 불평하려고 생각하는 것을 상용구 코드라고합니다. 예, 상속보다는 구성을 사용하려면 상용구 코드가 필요합니다. 무료로 노출되는 것은 없습니다. 노출하는 코드를 작성해야합니다. 보일러 플레이트는 상태의 유연성, 노출 된 인터페이스를 좁히는 기능, 추상화 수준에 적합한 다른 이름을 부여 할 수 있으며, 훌륭한 ol 간접적 인 정보를 제공합니다. 내부, 그래서 당신은 정상적인 인터페이스에 직면하고 있습니다.

그러나 예, 추가 키보드 입력이 많이 있습니다. 코드를 읽을 때 상속 스택을 위아래로 튀는 요요 문제 를 예방할 수 있다면 가치가 있습니다.

이제는 상속을 거부하는 것이 아닙니다. 내가 가장 좋아하는 용도 중 하나는 예외에 새로운 이름을 부여하는 것입니다.

public class MyLoginPageWasNull extends NullPointerException{}

DRY 원칙에 대한 일반적인 오해는 그것이 반복되는 코드 라인과 관련이 없다는 것입니다. DRY 원칙은 "모든 지식은 시스템 내에서 하나의 명백하고 권위있는 표현을 가져야합니다" 입니다. 코드가 아니라 지식에 관한 것입니다.

LoginPage로그인을 위해 페이지를 그리는 방법에 대해 알고 있습니다. EditInfoPage이를 수행하는 방법을 알고 있다면 이는 위반입니다. LoginPage비아 컴포지션 포함 은 DRY 원칙을 위반 하지 않습니다 .

DRY 원칙은 소프트웨어 엔지니어링에서 가장 잘못 사용되는 원칙 일 수 있으며 항상 코드를 복제하지 않는 원칙이 아니라 추상 영역 지식을 복제하지 않는 원칙으로 생각해야합니다. 실제로, 많은 경우 DRY를 올바르게 적용하면 코드를 복제하게되므로 반드시 나쁜 것은 아닙니다.

짧은 대답 : 그렇습니다.

언뜻보기에 상속은 때때로 "내 재사용 클래스에 모든 공용 메소드와 속성이 1 : 1 방식으로 포함됩니다"라고 말하는 효과가 있기 때문에 코드의 일부를 절약 할 수 있습니다. 따라서 구성 요소에 10 개의 메서드 목록이 있으면 상속 된 클래스의 코드에서 해당 메서드를 반복 할 필요가 없습니다. 컴포지션 시나리오에서 해당 10 개의 메소드 중 9 개가 재사용 컴포넌트를 통해 공개적으로 노출되어야하는 경우, 9 개의 위임 호출을 작성하고 나머지는 제거해야합니다.

이것이 왜 참을 수 있습니까? 컴포지션 시나리오에서 복제 된 메소드를 살펴보십시오. 이러한 메소드는 독점적으로 컴포넌트 인터페이스에 대한 호출을 위임하므로 실제 로직은 포함되지 않습니다.

DRY 원칙의 핵심은 동일한 논리 규칙 이 인코딩 되는 코드에서 두 위치를 사용하지 않는 것입니다. 이러한 논리 규칙이 변경 될 때 DRY가 아닌 코드에서는 해당 위치 중 하나를 쉽게 적용하고 다른 위치를 잊어 버리기 때문에 오류가 발생합니다.

그러나 위임 호출에는 논리가 포함되어 있지 않기 때문에 일반적으로 이러한 변경의 대상이 아니므로 "구성보다 상속을 선호"할 때 실제 문제가 발생하지 않습니다. 그리고 컴포넌트를 사용하는 모든 클래스에서 공식적인 변경을 유발할 수있는 컴포넌트의 인터페이스가 변경 되더라도 컴파일러는 호출자 중 하나를 변경하는 것을 잊었을 때 알려줍니다.

당신의 예제에 대한주의 사항 : 나도 몰라 방법 HomePage과 EditInfoPage같이, 그러나 그들은 로그인 기능을하고, 경우 HomePage(또는이 EditInfoPage) A는 LoginPage 다음 상속 여기에 올바른 도구가 될 수 있습니다. 구성이보다 분명한 방식으로 더 나은 도구가 될 수있는 논란의 여지가없는 예는 아마도 상황을 더 명확하게 만들 것입니다.

어느 가정 HomePage이나은 EditInfoPage각각 A LoginPage, 그리고 당신이 쓴대로 하나의 일부 부품이 필요 꽤 가능성이보다 하나, 후자를 재사용하고 싶어 LoginPage하지 다. 이 경우 표시된 방식으로 컴포지션을 사용하는 것보다 더 나은 방법이 있습니다.

• 재사용 가능한 부분을 LoginPage자체 구성 요소로 추출

• 해당 구성 요소의 재사용 HomePage및 EditInfoPage그 내부에 현재 사용되는 것과 동일한 방법으로LoginPage

그렇게하면 상속에 대한 구성이 왜 그리고 언제 올바른 접근법인지가 더 명확해질 것입니다.