취약한 기본 클래스 문제를 피합니다 . 모든 클래스에는 암시 적 또는 명시 적 보증 및 불변이 있습니다. Liskov 대체 원칙은 해당 클래스의 모든 하위 유형도 이러한 보증을 모두 제공해야합니다. 그러나를 사용하지 않으면이를 위반하는 것이 정말 쉽습니다 final. 예를 들어, 암호 검사기를 보자 :
public class PasswordChecker {
public boolean passwordIsOk(String password) {
return password == "s3cret";
}
}
해당 클래스를 재정의하는 경우 한 구현은 모든 사람을 잠글 수 있고 다른 구현은 모든 사람에게 액세스 권한을 부여 할 수 있습니다.
public class OpenDoor extends PasswordChecker {
public boolean passwordIsOk(String password) {
return true;
}
}
서브 클래스는 이제 원본과 매우 호환되지 않는 동작을 갖기 때문에 일반적으로 OK가 아닙니다. 만약 우리가 수업을 다른 행동으로 확장하고자한다면, 책임의 사슬이 더 나을 것입니다 :
PasswordChecker passwordChecker =
new DefaultPasswordChecker(null);
// or:
PasswordChecker passwordChecker =
new OpenDoor(null);
// or:
PasswordChecker passwordChecker =
new DefaultPasswordChecker(
new OpenDoor(null)
);
public interface PasswordChecker {
boolean passwordIsOk(String password);
}
public final class DefaultPasswordChecker implements PasswordChecker {
private PasswordChecker next;
public DefaultPasswordChecker(PasswordChecker next) {
this.next = next;
}
@Override
public boolean passwordIsOk(String password) {
if ("s3cret".equals(password)) return true;
if (next != null) return next.passwordIsOk(password);
return false;
}
}
public final class OpenDoor implements PasswordChecker {
private PasswordChecker next;
public OpenDoor(PasswordChecker next) {
this.next = next;
}
@Override
public boolean passwordIsOk(String password) {
return true;
}
}
더 복잡한 클래스가 자체 메서드를 호출하면 해당 메서드가 재정의 될 수 있습니다. 데이터 구조를 예쁘게 인쇄하거나 HTML을 작성할 때 때때로이 문제가 발생합니다. 각 메소드는 일부 위젯을 담당합니다.
public class Page {
...;
@Override
public String toString() {
PrintWriter out = ...;
out.print("<!DOCTYPE html>");
out.print("<html>");
out.print("<head>");
out.print("</head>");
out.print("<body>");
writeHeader(out);
writeMainContent(out);
writeMainFooter(out);
out.print("</body>");
out.print("</html>");
...
}
void writeMainContent(PrintWriter out) {
out.print("<div class='article'>");
out.print(htmlEscapedContent);
out.print("</div>");
}
...
}
이제 좀 더 스타일을 추가하는 하위 클래스를 만듭니다.
class SpiffyPage extends Page {
...;
@Override
void writeMainContent(PrintWriter out) {
out.print("<div class='row'>");
out.print("<div class='col-md-8'>");
super.writeMainContent(out);
out.print("</div>");
out.print("<div class='col-md-4'>");
out.print("<h4>About the Author</h4>");
out.print(htmlEscapedAuthorInfo);
out.print("</div>");
out.print("</div>");
}
}
이제 이것이 HTML 페이지를 생성하는 좋은 방법이 아니라는 것을 잠시 무시하고 레이아웃을 다시 변경하려면 어떻게됩니까? SpiffyPage어떻게 든 그 내용을 감싸는 하위 클래스 를 만들어야합니다 . 여기서 볼 수있는 것은 실수로 템플릿 메소드 패턴을 적용한 것입니다. 템플릿 메서드는 기본 클래스에서 재정의되도록 정의 된 확장 점입니다.
기본 수업이 바뀌면 어떻게 되나요? HTML 내용이 너무 많이 변경되면 서브 클래스가 제공하는 레이아웃이 깨질 수 있습니다. 따라서 나중에 기본 클래스를 변경하는 것은 실제로 안전하지 않습니다. 모든 클래스가 동일한 프로젝트에있는 경우에는 분명하지 않지만 기본 클래스가 다른 사람들이 개발 한 일부 게시 된 소프트웨어의 일부인 경우 매우 눈에.니다.
이 확장 전략을 의도 한 경우 사용자가 각 부품이 생성되는 방식을 바꿀 수있게되었습니다. 외부에서 제공 할 수있는 각 블록에 대한 전략이있을 수 있습니다. 또는 데코레이터를 중첩시킬 수 있습니다. 이것은 위의 코드와 동일하지만 훨씬 더 명확하고 훨씬 유연합니다.
Page page = ...;
page.decorateLayout(current -> new SpiffyPageDecorator(current));
print(page.toString());
public interface PageLayout {
void writePage(PrintWriter out, PageLayout top);
void writeMainContent(PrintWriter out, PageLayout top);
...
}
public final class Page {
private PageLayout layout = new DefaultPageLayout();
public void decorateLayout(Function<PageLayout, PageLayout> wrapper) {
layout = wrapper.apply(layout);
}
...
@Override public String toString() {
PrintWriter out = ...;
layout.writePage(out, layout);
...
}
}
public final class DefaultPageLayout implements PageLayout {
@Override public void writeLayout(PrintWriter out, PageLayout top) {
out.print("<!DOCTYPE html>");
out.print("<html>");
out.print("<head>");
out.print("</head>");
out.print("<body>");
top.writeHeader(out, top);
top.writeMainContent(out, top);
top.writeMainFooter(out, top);
out.print("</body>");
out.print("</html>");
}
@Override public void writeMainContent(PrintWriter out, PageLayout top) {
... /* as above*/
}
}
public final class SpiffyPageDecorator implements PageLayout {
private PageLayout inner;
public SpiffyPageDecorator(PageLayout inner) {
this.inner = inner;
}
@Override
void writePage(PrintWriter out, PageLayout top) {
inner.writePage(out, top);
}
@Override
void writeMainContent(PrintWriter out, PageLayout top) {
...
inner.writeMainContent(out, top);
...
}
}
top호출 writeMainContent이 데코레이터 체인의 상단을 통과하도록하려면 추가 매개 변수가 필요합니다 . 이는 개방형 재귀 라는 서브 클래 싱 기능을 에뮬레이트합니다 .
데코레이터가 여러 개인 경우 이제 더 자유롭게 믹싱 할 수 있습니다.
기존 기능을 약간 조정하려는 욕구보다 훨씬 더 자주 기존 클래스의 일부를 재사용하려는 욕구입니다. 나는 누군가가 당신이 항목을 추가하고 모든 항목을 반복 할 수있는 수업을 원했던 경우를 보았습니다. 올바른 해결책은 다음과 같습니다.
final class Thingies implements Iterable<Thing> {
private ArrayList<Thing> thingList = new ArrayList<>();
@Override public Iterator<Thing> iterator() {
return thingList.iterator();
}
public void add(Thing thing) {
thingList.add(thing);
}
... // custom methods
}
대신에 그들은 서브 클래스를 만들었습니다 :
class Thingies extends ArrayList<Thing> {
... // custom methods
}
이 갑자기 전체 인터페이스는 것을 의미 ArrayList의 일부가되었습니다 우리의 인터페이스를 제공합니다. 사용자는 remove()물건이나 get()특정 지수에 물건을 넣을 수 있습니다 . 이것은 그런 식으로 의도 된 것입니까? 승인. 그러나 종종 모든 결과를 신중하게 생각하지 않습니다.
따라서 다음을 권장합니다
extend신중한 생각 없이는 수업을하지 마십시오 .final메서드를 재정의하려는 경우를 제외하고는 항상 클래스를 표시하십시오 .- 예를 들어 단위 테스트와 같이 구현을 교체하려는 인터페이스를 만듭니다.
이 "규칙"이 깨져야 할 많은 예가 있지만, 일반적으로 유연하고 좋은 디자인으로 안내하고 기본 클래스의 의도하지 않은 변경 (또는 기본 클래스의 인스턴스로서 서브 클래스의 의도하지 않은 사용)으로 인한 버그를 피합니다. ).
일부 언어에는보다 엄격한 시행 메커니즘이 있습니다.
- 모든 방법은 기본적으로 최종적인 것으로 명시 적으로 표시되어야합니다.
virtual
- 인터페이스를 상속하지 않고 구현 만하는 개인 상속을 제공합니다.
- 기본 클래스 메소드를 가상으로 표시해야하고 모든 대체를 모두 표시해야합니다. 이것은 서브 클래스가 새로운 메소드를 정의했지만 나중에 동일한 서명을 가진 메소드가 기본 클래스에 추가되었지만 가상으로 의도되지 않은 문제점을 피합니다.
final입니까? 저를 포함한 많은 사람들이 모든 비 추상적 인 수업을 만드는 것이 좋은 디자인이라는 것을 알게되었습니다final.