問題タブ [open-closed-principle]

Interface Segregation Principle と Open/Closed Principle の違いがわかりません。

私が理解しているのは、ISPはすべてをインターフェイスに依存させ、OCPをクラスに依存させる必要があるということです。どちらも同じ方法で実装できますが、インターフェイスを使用するものとクラスを使用するものがあります。

Open-Closed Principle に基づいていくつかのコードをリファクタリングしようとしましたが、デザイン パターンの適用に関しては、次のクラスを正しく取得できないようです。(以下に概説する多くのクラスをお詫びします - 可能な限りそれらを減らしましたが、残りは私のデザインを示すために必要です)。

セットアップは、次のクラスで構成されます。

その上PtpPort、私はPonPort実装していますが、実装IInternetPortしているCatvPortだけIPortです。

すでにこのコードには、コード臭の兆候があると思います。inCreatePortでは、キャストするのではなく、PtpPortFactory受け入れるPtpPortDetails(から継承する) ことができます。PortDetailsただし、そうすると、PonPortFactoryも実装する を作成できません。IPortFactoryこれらのポートにはPonPortDetails. またはCatvPortFactoryそのことについて。

ポート ファクトリを使用すると、別のコードの匂いがします。

IPortfrom からto へのダウンキャストを実行する必要はIInternetPortなく、単にCreatePortreturnが必要IInternetPortです。

上記を理解するために必要な最後の情報は、おそらく次のクラスです ( Jimmy Bogards クラスに基づくEnumeration)。

途中で誰かが私を助けてくれることを本当に願っています(ジェネリックを導入しようとしましたが、戻り値の型の共分散をサポートしていないC#の障壁に常にぶつかっているようです)。

さらに、より良いコードを書くための道に沿って私を助けるための他のヒントとコツは大歓迎です。

アップデート

コメントでリクエストがあったため、以下にさらにコードを追加しました。

Port突然タイプもあるという事実に混乱しないでください。これは別の境界付けられたコンテキスト (DDD の意味で) の集約です。IInternetPortアルゴリズムは、メソッドをOfCapability内部的に使用してポートを選択するため、 のリストを入力として受け取る必要があります。ただし、アルゴリズムが正しいポートを選択した場合、単に に関心があるだけなIdので、戻り値の型は単にIPortです。

オブジェクト指向モデリングとデザインの試験の準備をしていますが、この問題がわかりません。

設計は開閉原則に違反しています。クラスを変更せずに JButton を追加することはできません。これが可能になるように設計をやり直してください。デザインには、3 つのボタンとイベント管理が含まれている必要があります。コードの重複を避けます。クラス図を使用して新しい設計を提示します。

ご参考までに、Open-Closed Principle (OCP): https://www.cs.utexas.edu/users/downing/papers/OCP.pdf

OOP コースはほぼ終了しましたが、OCP と、なぜ RTTI が違反しているのかについて質問があります。アイデアはありますが、自分が正しいことを確認したいだけです。

スーパークラスのメソッドをオーバーライドし、RTTI を使用して型が同じかどうかを確認する場合のように、RTTI を使用して何かが基本クラス (スーパータイプ) の型であるかどうかを推測する場合、RTTIは OCP 原則を無効にしません。タイプ。equals(o: Object)o

RTTIがOCP を無効にしない同様のケースはありますか?

最後に、スーパータイプ内のサブタイプのインスタンスをチェックするときに RTTIがOCP を無効にし、スーパータイプのソース コードを変更して OCP を無効にするケースはありますか (明らかに変更のために閉じられていませんでした)?

以下のコードで、外部メソッド パラメーター ( ) としてプライベート メンバー を渡すことは_field、class FooSOLIDプログラミング プラクティスのOpen/Closed 原則Bar.DoSomething(_field)に違反しますか?

オブジェクト指向プログラミングでは、オープン/クローズの原則により、「ソフトウェア エンティティ (クラス、モジュール、関数など) は、拡張に対してオープンである必要がありますが、変更に対してクローズされている必要があります」と述べられています。つまり、そのようなエンティティは、ソース コードを変更せずに動作を拡張できます。

私が理解しているように、エンティティは拡張に対して開かれている必要がありますが、変更に対しては閉じられています。ただし、この場合、 is はand is_fieldのコンストラクターで一度設定されます。プライベート メンバーを外部メソッドのパラメーターに渡すことは、オープン/クローズの原則またはその他のベスト プラクティスに違反していますか?Fooreadonly