問題タブ [open-closed-principle]

私は、たくさんのテンプレートとそれらの専門分野で取り組む新しいプロジェクトに深く関わっています。さて、プログラミングをせずに1日を過ごした後、私はそれが本当に余分なコード行の価値があるかどうかを自問していることに気づきました。

問題は、専門化の利点は何ですか？

これは：

とにかくより良い（より速い実行）

？

編集：

このコードは、他の人が使用するライブラリの一部です。私はgcc4.6.3を使用していますが、最終的にはコードはさまざまなコンパイラで使用されます。

編集：

これらの2つのコードは、gcc4.6.3を使用して同一のバイナリになります。私の実際のコードは使用可能にはほど遠いため、完全なケースをテストすることはできません。それは本当に原則、汎用性、再利用性、保守性などの問題のようです...

Open-Closed Principleは次のように述べています。

ソフトウェア エンティティ (クラス、モジュール、関数など) は、拡張用に開いている必要がありますが、変更用に閉じている必要があります。

現在、ドメインを設計しており、ドメイン エンティティにかなりの動作を含めています。私はドメイン イベントを使用し、依存関係をメソッドに注入しているので、エンティティが外部の影響に結合されていないことを確認してください。ただし、クライアントが後でより多くの機能を必要とする場合は、OCP に違反し、これらのドメイン エンティティをクラックして機能を追加する必要があります。振る舞いが豊富なドメイン エンティティは、どうすればオープン クローズド プリンシプルと調和して生活できるでしょうか?

以下の UnitOfWork クラスの使用を改善する方法を調べるのは興味深いことです。ご覧のとおり、現在 UnitOfWork インターフェイスがないため、MVC コントローラーでこれを使用する場合、コントローラーをこのクラスに依存させる新しいオブジェクトを作成する必要があります。

Ninject を使用して、コントローラーのコンストラクターにインターフェイスを渡すことにより、この依存関係を注入できるようにしたいと考えています。私の問題は、このクラスが現在、オープン/クローズドの原則を満たしていないことです。改善方法に関する誰かの提案に興味があります。それ。リポジトリをこの作業単位に渡す何らかの方法も必要だと思いますが、その方法については完全にはわかりません。

どんな助けでも感謝します、ありがとう。

特定の国の郵便番号が必須かどうかを、countryid提供されたコードに基づいて確認する必要があります。現在、私はswitchステートメントでこれを行っていますが、このコードは Open/Closed SOLID の原則を破っています。switchこのシナリオでを取り除く方法を知りたいです。

プログラムはログ ファイルを解析します。各ログ ファイルは、異なる種類のフィールド形式 (固定幅、カンマ区切りなど) を持つ場合があります。また、各ログ ファイルにはいくつかの異なる種類のログが混在しています (種類ごとに異なるフィールド定義があります)。たとえば、CSV ログ ファイルは次のようになります。

ログファイル A

以下はコードです。次のコードで、いくつの固い原則に違反していますか? ある人は、レイアウト定義のリストを解析ログと混ぜてはいけないと言いました。では、少なくとも SRP に違反していますか (またはそれ以上)? 構造をリファクタリングする最良の方法は何ですか?

メイン プログラムは、ファイル名のパターンに従って LogFileList から項目を取得し、ログ ファイルを 1 行ずつ読み取り、プロパティを割り当て、Row解析された文字列を取得します。

Head First Design Pattern を使用して Object Oriented Design パターンを学習しようとしています。これは、本からのファクトリーパターンの一例です。ここでは、オープンクローズの原則に違反することなく、新しいピザアイテムを追加したいと考えています。本のサンプル コードでは、新しいピザ アイテム クラスを追加する場合、PizzaStore クラスと PizzaOrder クラスを変更する必要があります。しかし、他のクラスを変更せずに、新しいピザ アイテムを追加したいだけです。

}

この PizzaStore クラスは、ピザを作成して注文するためのものです。

}

これは、ピザの抽象クラスです。

このクラスは、顧客から注文を受けるために使用されます。

これは私の新しいピザ アイテム クラスです。chicagoPizzaStore と testDrive クラスを変更せずに、このピザを注文したいと思います。

次のことを考慮してください。

InnerClassは静的ではないため、外部クラスのインスタンスに対して作成する必要があります。

new OuterClass().new InnerClass()

通常の内部クラスは、それが作成された外部クラスへの参照を保持します。これは、を使用してアクセスできますOuter.this.myAttribute（「ネーミングコリジョン」がある場合に特に役立ちます）。

匿名内部クラスを作成する場合も同じです。作成された匿名内部クラスは外部クラスへの参照を保持します。これが、メソッド内で述語を宣言するときに（匿名メソッド-ローカル内部クラス）、内部クラス内で引き続きアクセスできる理由です。アウタークラスの変数は、finalを宣言する必要はありません（メソッドパラメーターとして渡される変数の場合はそうする必要があります）。

そして最後に、インターフェイスで定数を宣言できます。これは、暗黙的にpublicstaticfinalとマークされています。オブジェクトは定数にすることができます。したがって、匿名の内部クラスとして作成されたオブジェクトは、インターフェイスの有効な定数です。

たとえば、Guavaを使用する場合、通常、インターフェイス関数と述語で宣言します。これにより、のような便利なGuava関数を利用できるようになりMaps.uniqueIndex(...)ます。

だからあなたは私の質問は何ですか？ここにあります：

匿名クラスをインターフェース定数として宣言する場合（私の最後のコードサンプルを参照）、匿名内部クラスはどの外部クラスへの参照を保持しますか？

私はVisitor Patternをよくマスターします。しかし、私は何か疑問に思っています。

ビジター パターンを使用する最も重要な動機は、実際のデータ オブジェクト タイプをチェックする必要なく、クライアント側で特定のデータ モデルを含むロジックを追加することです。解決に使用される手法は、Double-Dispatching と呼ばれます。

したがって、accept()メソッドを実装するデータ モデルのコード スニペットは次のとおりです。

そしてここにPrintCarVisitor実装Visitorインターフェースがあります：

したがって、if/elseシリーズとinstanceofシリーズは必要ありません。

すべてのクライアントは次のようになります。

しかし、Visitor は Open/Closed Principle を保持していないため (新しいデータ モデルが独自のvisitメソッドを追加することでクラスを破壊するため)、なぜわざわざ二重ディスパッチを行うのでしょうか?

if/elseビジターの実装内でシリーズを分離することはできませんか。

この仮想的な代替案を使用すると、コードのこの部分が消えます。

PrintCarVisitorだろう：

この代替手段を使用しても、すべての呼び出し元は、次のようにデータ モデルの抽象化を処理します。

new PrintCarVisitor().visit(car); //no need to know the exact data type in client side

アプリオリに、この 2 番目のアプローチは、純粋な Visitor パターンの実装中に生成されるすべてのボイラープレートを必要としないため、優れています。

このアプローチには 2 つの欠点があると思います。

1)Visitor使用されたビジターがCar現在処理されているメソッドに対応するメソッドを破棄するという保証はありません (インターフェイスが課すように)。

2) BoilerPlate コードは、一連のinstanceofおよびを使用して、Visitor 実装クラスにより重いままcastingです。

Visitor Pattern が Double Dispatching を使用する必要がありinstanceof、クラス内でシリーズを単純に分離できない理由を説明する他の欠点はありますか (Factoryたとえば、静的なように)?

ウィキペディアから：

クラスの実装は、一度完了すると、エラーを修正するためだけに変更できるという考えでした。新しい機能または変更された機能では、別のクラスを作成する必要があります。そのクラスは、継承によって元のクラスのコーディングを再利用できます

私が理解していることから、Visitor パターンは、同じインターフェイスを実装する類似しているが異なるオブジェクトをダブルディスパッチを使用してトラバースするための強力な手法です。私の Java の例の 1 つで、ツリー構造を形成するオブジェクトの複合セットを作成し、それらのオブジェクトのそれぞれの特定の実装が、訪問可能なインターフェースを実装しています。ビジター インターフェイスには、訪問可能なオブジェクトごとにメソッドがあり、具体的なビジターは、これらのケースごとに何をすべきかを実装します。

私が理解しようとしているのは、visitable も実装する複合構造に新しい実装を追加する場合、ビジター インターフェイスを再度開いてそのケースを追加する必要があるという事実です。ビジターの各実装を変更します。

とにかくこれを行う必要があるため (ビジターがビジターブルを理解できない場合、ビジターブルに追加するメリットはありますか?)、これは問題ありませんが、学術レベルでは、これはオープン クローズドの原則に違反していませんか? とにかく、それがデザイン パターンの主な理由の 1 つではありませんか? すべての switch ステートメントを終了するために switch ステートメントを維持する代わりに、このパターンに切り替える適切な理由を示そうとしていますが、switch ブロックの代わりに各ケースのメソッドを使用して、とにかくコードは同じであると誰もが主張しています。そして読みにくい。

Open-Closed Principleのウィキペディアのページ(2013 年 2 月 27 日現在) には、継承によって実現されていると書かれています。

Open/Closed Principleという名前は、2つの方法で使用されています。どちらの方法も継承を使用して明らかなジレンマを解決しますが、目標、手法、および結果は異なります。

「2 つの方法」とは、Meyer の実装の継承と、より一般的なポリモーフィック拡張を指します。

とにかく、私の質問は、継承を使用しないFaçadeパターンについてです。より複雑なサブシステム (またはライブラリ) への単純化されたインターフェイスの形で抽象化を定義するため、これは Open-Closed Principle と見なすこともできませんか? すなわち：

サブシステム (またはライブラリ) は、Façade を使用するクライアントへの拡張用に開かれており、そのインターフェイスは変更に対して閉じられています。

それとも、情報隠蔽の境界を広げているだけなのでしょうか (OCP に非常に近く、特にProtected Variationsと見なす場合)。