オープン継承

これは、DesignedInheritanceに対する逆の態度です。オープン継承の支持者は、クラスをSealによって継承を許可しないことや、他の人によるクラスの継承を阻止するための措置を講じることを考えていません。

オープン継承の愛好家は、継承の危険性に関する設計継承の愛好家とは意見が一致していません。継承は、油断している人には多くの危険が潜む密接な関係です。スーパークラスの動作を簡単に壊すことができ、隠された実装の詳細に依存するため、特にアップグレードには注意する必要があります。しかし、オープン継承者は、そのようなリスクを引き受けるかどうかはライブラリのユーザーが決定すべきだと考えています。継承することを選択した場合、そのリスクとその結果を受け入れる必要があります。

設計されたアプローチは理論的には優れていますが、問題は誰かが既存のクラスをどのように有用に変更できるかをすべて把握することが非常に難しいことです。このため、2 つの問題が発生します。ライブラリのユーザーは設計者が予想していなかった方法でライブラリを使用することができず、ライブラリの設計者は拡張を予測しようとする責任を負う必要があります。

設計された継承は、ライブラリライターはユーザーよりも賢いと想定しています。多くの場合、そうではありません。ライブラリライターも間違いを犯します。継承がオープンであれば、クラスのユーザーはそれらを修正し、ライブラリライターの努力を活用する機会を得ることができます。

継承向けに設計することは非常に面倒な作業です。特に、通常はユースケースがわかりません。人々にすべての継承ケースを考えるよう依頼することは、ライブラリのライターに大きな負担をかけます。オープン継承とは、継承する人が自分のやっていることに注意すれば、特にそれを望まない限り、それに対処する必要がないことを意味します。

設計された継承に特に問題を引き起こす領域の 1 つはテストです。テストでは多くの場合TestDoubleを使用する必要がありますが、置換に使用できるインターフェイスのない封印されたクラスによって妨げられます。そのような API はDetestableになる可能性があります。

オープン継承者は、安全に使用できる意図した拡張ポイントを備えたクラスを設計することがよくあります。ただし、通常はそれらをシールするのではなく、名前付けやドキュメントでマークします。このようにして、安全な領域を人々に示しますが、必要な場合は他をオーバーライドすることを妨げません。

多くの場合、設計継承にはDirectingAttitudeが伴います。これは、愚か者は物事をめちゃくちゃにするのは得意であることを忘れていることがよくあります。