したがって、元のコードを作成したときは、LabTest クラスと言うだけで済みました。しかし、RadiologyTest、EKGTest などを追加する新しい要件があるとしましょう。
これらのクラスには多くの共通点があるため、基本クラスを持つことは理にかなっています。
ただし、これは LabTest クラスを変更する必要があることを意味します。そのインターフェイスは以前と同じままであるとしましょう。つまり、LabTest クラスのコンシューマーは変更する必要がありません。
これはオープン・クローズド・プリンシパルの原則に違反していませんか？(LabTest は変更中です)。
これらのクラスには多くの共通点があるため、基本クラスを持つことは理にかなっています。
SRPに違反している可能性があります。結局のところ、各クラスが 1 つのタスクを実行する場合、2 つ以上のタスクがどのように似ているのでしょうか? 両方が同じように実行するタスクがある場合、それは別のタスクであり、別のクラスで実行する必要があります。
だから私は、最初LabTestにそれを構成する部分にリファクタリングすると言います（ユニットテストがあることを願っています！）。それからあなたが書くようになったときRadiologyTest、EKGTest彼らは彼らにとって意味のある部分を再利用することができます. これは、継承に対する合成とも呼ばれます。
ただし、何をするにしても、クライアントでこれらのクラスへのインターフェイスを使用してください。従う人に、基本クラスを使用して拡張機能を追加することを強制しないでください。
Open-Closed Principle (Uncle Bob と Bertrand Meyers が概説したように) は、クラスを決して変更しないということではないと思います (ソフトウェアが決して変更されないのであれば、それはハードウェアである可能性もあります)。
LabTest＆あなた自身の場合、クラスのすべての使用はの実装ではなくの抽象化に依存していると述べたので、OCPに違反しているとは思いませんRadiologyTest。
Uncle Bob の入門論文から、OCP 用に設計されている場合、新しいサブクラスがシステムに追加されるDrawAllShapesたびに変更する必要がないクラスの例があります。Shape適用するレベルについて、ボブおじさんは次のように述べています —</p>
重要なプログラムを 100% クローズすることはできないことは明らかです。例えば、 allを any の前に描画する必要があると
DrawAllShapes判断した場合、リスト 2 の関数がどうなるかを考えてみてください。このような変更に対して関数はクローズされません。一般に、モジュールがどれほど「閉じられている」かに関係なく、閉じられていない何らかの変更が常に存在します。CirclesSquaresDrawAllShapes閉鎖は完全ではないため、戦略的でなければなりません。つまり、設計者は、設計を終了する変更の種類を選択する必要があります。
「変更のためにクローズ」を「リファクタリングしないでください」とは読みません。それ以上に、他のクラスがあなたに影響を与える変更を加えられないようにクラスを設計する必要があります。たとえば、基本的な OO のものを適用します — カプセル化ゲッター/セッターとプライベートメンバー変数を介して。