壊れやすい基本クラスの問題を回避します。すべてのクラスには、暗黙的または明示的な保証と不変式のセットが付属しています。Liskov Substitution Principleでは、そのクラスのすべてのサブタイプもこれらすべての保証を提供する必要があります。ただし、を使用しない場合、これに違反するのは本当に簡単finalです。たとえば、パスワードチェッカーを使用してみましょう。
public class PasswordChecker {
public boolean passwordIsOk(String password) {
return password == "s3cret";
}
}
そのクラスのオーバーライドを許可すると、1つの実装が全員をロックアウトし、別の実装が全員にアクセスを許可する可能性があります。
public class OpenDoor extends PasswordChecker {
public boolean passwordIsOk(String password) {
return true;
}
}
これは通常、サブクラスの動作が元のものと非常に互換性がないため、通常は問題ありません。もしクラスが他の振る舞いで拡張されることを本当に意図しているなら、責任の連鎖がより良いでしょう：
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()特定のインデックスで物事をすることができます。これはそのように意図されていましたか？OK。しかし、多くの場合、すべての結果を慎重に検討しません。
したがって、以下をお勧めします
extend慎重に考えずにクラスを作ることはありません。finalメソッドをオーバーライドする場合を除き、常にクラスにマークを付けます。- 単体テストなど、実装をスワップアウトするインターフェイスを作成します。
この「ルール」を破る必要がある多くの例がありますが、通常は適切で柔軟な設計に導き、基本クラスの意図しない変更（または基本クラスのインスタンスとしてのサブクラスの意図しない使用）によるバグを回避します。 ）。
一部の言語には、より厳格な実施メカニズムがあります。
- すべてのメソッドはデフォルトで最終であり、明示的にマークする必要があります
virtual
- インターフェイスを継承せず、実装のみを継承するプライベート継承を提供します。
- 基本クラスメソッドを仮想としてマークする必要があり、すべてのオーバーライドもマークする必要があります。これにより、サブクラスが新しいメソッドを定義したが、同じシグネチャを持つメソッドが後で基本クラスに追加されたものの、仮想として意図されていないという問題を回避できます。
finalですか？多くの人々（私を含む）は、すべての非抽象クラスを作成するのが良いデザインであることに気付きfinalます。