問題タブ [open-closed-principle]

私は一連の WCF サービスの開発と保守を行っています。機能はサービスにグループ化されています。支払いはあるサービスに、純粋なデータは別のサービスに、アプリケーション機能 (主に CRUD) は 3 番目のサービスに分類されます。

リリース サイクルごとに、別のチームがクローズド データベースから何かを要求するので、データ サービスにメソッドを追加します。

私たちは、前任者のひどいコーディング (ループの代わりにハンガリー語表記とネストされた try/catch を使用していた) から離れて、オブジェクト指向プログラミングのようなものに移行しようとしています。

オープン/クローズの原則は、毎回新しいサービスを作成せずに、WCF で作成されたサービスに適用できますか? 時間をかけて試す価値はありますか？

ありがとう。

オープンクローズの原則とは、拡張に対してオープンで、変更に対してクローズであることを知っています。次の例を考えてみましょう

これで、Open Closed Principle を使用してBikeクラスが拡張され、新しい機能が追加されたことがわかります。Vehicle

Vehicleクラスのjarファイルを作成し、クラスがjarからBikeクラスを拡張するとしますVehicle。この場合、Vehicleクラスを変更してBike拡張することはできません。オープンクローズド原則の良い例ですか？OCP が継承とどう違うのか知りたい

グラフィカル ユーザー インターフェイスを持つ C++ の大規模なプロジェクトに取り組んでいます。ユーザー インターフェイスは、オブザーバー パターンに依存する設計パターン (MVVM/MVC) を使用します。

私の問題は、現在、モデルのどの部分を観察可能にするかを予測する方法がないことです。そして、たくさんのパーツがあります。

この問題により、いくつかの方向に引っ張られていることに気づきました。

1. 通知をサポートしないバックエンド クラスを開発すると、Open-Closed 原則に違反していることに気付くでしょう。
2. すべてのモデル クラスとそのすべてのデータ メンバーへの通知のサポートを提供した場合、実際に必要なのはこのサポートの一部のみであるため (この部分は不明ですが)、正当化されないほどの膨大なパフォーマンス コストが発生します。
3. すべての非 const メソッドを仮想化し、これらのメソッドにベースポインターを介してアクセスすることによって、拡張のサポートのみを提供する場合も同様です。これには、可読性にもコストがかかります。

この 3 つのうち、(1.) の方がおそらく害が少ないと思います。

ただし、理想的なソリューションが実際にいくつかの言語 (間違いなく C++ ではない) に存在する必要があるように感じますが、それがどこでもサポートされているかどうかはわかりません。

私が考えていたユニコーンの解決策は次のようなものです: クラス Data が与えられた場合、 Data を観察可能にしようとするクライアントが次のようなことを行うことは可能ではないでしょうか?

@MakeObservable(データ)

コンパイル時の構造として。これにより、Data オブジェクトで addObserver を呼び出し、notifier を使用してデータ メンバーへのすべての割り当てを変更できるようになります。また、得たものに対してのみパフォーマンスで支払うようになります。

だから私の質問は2つあります：

1. 私が述べた 3 つの選択肢のうち、(1.) はより少ないが必要な悪であると仮定するのは正しいでしょうか?
2. 私のユニコーン ソリューションはどこかに存在しますか? 取り組んでいますか？それとも何らかの理由で実装できないでしょうか？

「OCP Java SE 6 Programmer Practice Exams (Exam 310-065)」Assessment test 2 の問題。

与えられた:

結果は？

A. c 1 c 1

B. c 1 c 2

C. cc 1 1

D.cc 1 2

E.cc 2 2

F. コンパイルが失敗します。

G. 実行時に例外がスローされます。

本に書かれている答えはC.

しかし、このコードを実行しようとすると、「静的フィールド WeatherTest.Weather.RAINY は静的な方法でアクセスする必要があります」というコンパイル エラーが発生します。

どちらが正しいと予想されますが、インターネット上で誰も文句を言っていないので、何か不足しているのではないかと思いますか? Javaのバージョンとか関係あるの？

Sting をオブジェクトに変換する、このようなコードがあります。ただし、最初のノードと最後のノードを示すために、 for ループ内に if ステートメントが含まれています。これよりも優れたコーディングはありますか?

オープン クローズドの原則に従って、新しい関数やコンテンツを追加するときにクラス、インターフェイス、コードなどを変更する必要があることはわかっていますが、この場合もファイルですか?

私はゲームを設計していました。ゲームにはいくつかのモンスター情報があり、追加または更新する新しいモンスターがある場合、ゲーム (クライアント側) は一部のファイルをダウンロードまたは置換する場合があります。

モンスター情報のフォーマットをどうするか悩んでいたのですが、モンスター情報を1ファイルにするか、モンスターごとに個別ファイルにするか。

1. すべてのモンスター情報を 1 つのファイル (例:monsterlist.json) に保存します。新しいモンスターを追加するたびに、ファイルが置き換えられます。

2.各モンスターには個別のファイルがあり、新しいモンスターを追加するたびに、新しいモンスターjsonも追加されます。

モンスター1.json

モンスター2.json

最初は、モンスターを追加または更新するときにmonsterlist.jsonを置き換えるだけでよいため、ケース1が最も便利だと思いますが、ケース2の場合、どのjsonが新しいかを知る必要があります（更新ステータスを保存するために追加の行が必要になる場合があります）サーバー データベース内)。

しかし突然、オープン クローズの原則を思い出しました。何か新しいものを追加しても現在のコンテンツは変更されるべきではありません。新しいモンスターが追加されたときにファイルを置き換えるのは合理的ではないようです。

上記は、「ファイル」がオープンクローズの原則に含まれていると私が考える理由の単なる例であり、どちらの形式が優れているかを尋ねるものではありません。私が聞きたいのは、どのファイル形式が優れているかではなく、オープンクローズド原則の定義です。「ファイル」に言及している定義が見つからないため、確認されれば、どのファイル形式を使用するかを推測できます。

C# を紹介する Java プログラマー (初心者) として、既に実装されているメソッドをこのように再抽象化できることを発見しました (この回答のコード) 。

これにより、クラス D の元の実装が完全に利用できなくなるわけではなく、サブクラス化 E (メソッドを再抽象化するクラス) を通じてサブクラス化する D のサブクラスでのみ利用できるようになるわけではないことを認識しています。クラス D が生産されていた場合の問題。

それでも、私は疑問に思っています。これはクラス D のコントラクトを変更しているのではなく、サブクラスの MUST override を指定していませんDoWork(int i)か? これは、オープン/クローズの原則に反していませんか?

これによって壊れた実際のコードや理論上のコードさえも持っていないことに注意してください。