問題タブ [solid-principles]

IRegistrationServiceと呼ばれるクライアント登録用のインターフェイスがあります。これにはRegisterという1つのメソッドが含まれており、RegistrationServiceクラスを介して実装されます。たとえば、Delete、Update、Retrieveのメソッドが必要な場合は、IDeletionService、IUpdateService、IRetrieveServiceなどのアクションごとに個別のインターフェイスを作成するか、すべてのメソッドをIRegistrationServiceに配置します。私がこれを尋ねる理由は、これがSOLIDの原則、特にSRPの原則が求めているように見えるからです。

オブジェクト指向設計でSOLID原則を順守していないことについて私が耳にする最も頻繁な議論の 1 つは、YAGNIです(ただし、議論者はそれをそう呼ばないことがよくあります)。

「機能 X と機能 Y の両方を同じクラスに入れても問題ありません。わざわざ新しいクラス (つまり、複雑さ) を追加する理由は非常に単純です。」

「はい、すべてのビジネス ロジックを直接 GUI コードに入れることができます。はるかに簡単かつ迅速です。これは常に唯一の GUI であり、重要な新しい要件が発生する可能性はほとんどありません。」

「万が一、新しい要件が発生してコードが乱雑になった場合でも、新しい要件に合わせてリファクタリングできます。そのため、『後で…が必要になったら』という議論は重要ではありません。」

そのような慣行に対するあなたの最も説得力のある議論は何ですか? 特にソフトウェア開発の経験があまりない人にとって、これが費用のかかる慣行であることをどのように実際に示すことができますか。

私はSOLIDの原則に従って設計するように一生懸命努力しています。私が見つけたのは、「単一責任の原則」（SOLIDのS）を使用する場合、通常、データコンテナとデータプロセッサの間でクラスを分割する必要があるということです。たとえば、すべてをクラス内に配置するのではなく、DBから読み取られる5つのプロパティを持つクラスpersonがある場合、プロパティを持つPersonクラスと、データベースからその情報を読み取ってPersonを作成する別のPersonReaderクラスを作成します。

その場合、PersonReaderがアクセスできるように、Personプロパティを開く必要がありますが、すべてをブラックボックスに入れてプロパティを読み取り可能にするよりも、カプセル化が少なくなります。

私は何かが足りないのですか、それともこれはこの原則の欠点ですか？

前もって感謝します

編集：最初にプロパティセッターを公開する必要がなかったので、私はパーソンライターをパーソンリーダーに変更しました。

リスコフの置換原則（SOLIDの「L」）を、原則のすべての側面を簡略化した方法でカバーする優れたC＃の例で説明できますか？それが本当に可能なら。

ウィキペディアから:

原則は次のように述べています。

A わかります。

しかし、(B)の「 Details 」の定義を書くのに問題があります。

DEFINITIONという用語をどのように定義できますか? それは正確には何を表していますか？

ありがとう！

SOLID開発イデオロギーの2つの優れた結果は、次の
とおり
です
。

SOLIDは言語に依存しない設計アイデアのセットですが、一部の言語は本質的に他の言語よりもこれらのアイデアをサポートしています。すぐに使用できる、またはさまざまなカスタマイズを行った後、読みやすく、機能を拡張しやすい言語として最適な言語はどれですか。

バイアスと炎上戦争を先取りするためのいくつかの定義：

• 読みやすさ：コードの量に比例するコードを理解するために行われる思考の量：（amount_think-energy / amount_code）はかなり一定であり、最適な場合には可能な限り低くなります。
• 拡張性：X量の機能を追加するには、コードを変更するか、Xに比例してコードを追加する必要があります（amount_added_functionality / amount_added_code）はかなり一定であり、最適な場合は可能な限り高くなります。

サポート情報とチュートリアルをお勧めします。コードスニペットを歓迎します。

私は現在、IoC コンテナーを使用する利点を学び、DI に慣れようとしています。私は StructureMap を使用し始めました。これは、かなり単純でありながら強力に思えるためです。

これらの概念に対する私の理解が正しいことを確認したいと思います。アプリケーションで次の基本的なクラスを想定してみましょう (簡潔にするために詳細は省略されています)。

まず第一に、Dependency Inversion Principle は、OrderService は「高レベル」モジュールであるため、下位レベルの実装の詳細に依存するべきではなく、それらのクラスへの参照を持ち、それらに要求できるようにする必要があると述べています。消費するコードは、これらの事前構成されたモジュールを作成してそれに渡す責任を負う必要があります。そうですか？したがって、DI はこれらのクラスを疎結合に保ち、その依存関係のメソッドが呼び出される正確な方法を知る必要がないようにします。呼び出されて、必要なことは何でも実行します。OrderService は、リポジトリが XML を照会しているか、NHibernate や EF、さらには生の DataSet を使用しているかを気にしません。リポジトリを呼び出して、ID が 42 の Order を見つけるように指示するだけで、リポジトリは何をすべきかを認識します。

また、IoC コンテナー (この場合は StructureMap) が、これらすべての依存関係を手動で作成して渡すことを強制しないことでメリットがあることも理解しています。たとえば、簡単なアプリの Main メソッドを使用して、上記のコードには次のものがある可能性があります。

これは、それを設定するためのすべてのニュースで非常に醜いです。変数を作成したとしても、それはまだ醜いです。IoC コンテナーを使用すると、これらすべてを回避できます。StructureMap の場合は次のようになります。

これははるかにクリーンで、保守が容易で、単体テストを書いている場合は、たとえばモックの具象クラスをサブアウトできます。要するに、利点は、特定のクラスが何に依存しているか (つまり、呼び出し元のコード) を気にする必要さえないところまで、すべてをさらに分離できることです。コンテナーを使用してクラスを作成し、実行させることができます。それは問題であり、消費するコードが必要なものだけを知っていることを確認します。たとえば、実際のアプリでは、コントローラーがサービスを呼び出している場合、リポジトリ、電卓、または仕様について知る必要はありません。知る必要があるのは、使用することだけですOrderService で Order を処理します。

この理解は正しいですか？その点については、まだわからないことがいくつかあります。

1. IoC コンテナーを使用することにした場合、それはアプリケーションのあらゆる場所で使用されることを意図していますか?それは、解決する逆依存関係が多数ある場合のみですか?それともコンシューマーでのみ使用することを意図していますか? たとえば、具体的な実装を使用して Order を新規作成している場合、OrderRepository で。このクラスは、Order を取得するために StructureMap も使用しますか? これはややばかげた質問かもしれませんが、私が見たすべての DI/IoC の例は、消費するクライアント (Web ページなど) での使用にのみ焦点を当てており、他の場所での使用には決して触れていません。それは全か無かのアプローチのようです。IoC コンテナーを使用する場合は、どこでも使用されます。new SomeObject();この場合、基本的に呼び出しを次のように置き換えています。ObjectFactory.GetInstance<ISomeObject>();

2. DI/IoC を使用する必要があるかどうか、またはそれをモックするようなものを使用する必要があるかどうかにかかわらず、すべてのクラス (もちろん可能であれば) をインターフェイスから派生させることは良いことでしょうか? 組み込みクラスではないすべてのクラスの背後にインターフェースがある多くのコード例を見てきましたが、これを行うことの利点と将来の保証の可能性を見ることができます.TDDまたはBDDに従うことはこれらの方法論を使用すると、通常、クラスのインターフェイスが必要かどうかがわかりますが、TDD であろうとなかろうと、オブジェクトの型を具体的なクラスとして定義するべきではないと感じている多くの人々を見て話しました。それは常にすべきです基になる型としてインターフェイスまたは抽象クラスになります。これは、YAGNI 違反は言うまでもなく、"Needless Complexity" コードの臭いのケースのようです。

重複
の可能性: オープン/クローズの原則

オープン/クローズの原則がそれを示唆していることは理解できます

とはどういう意味ですか?

JavaScriptの開発中にSOLIDプログラミングの原則（またはその一部）を使用した人はいますか？

読み始めたばかりですが、JSで使っている人が見つからないようです。私が実装/使用しやすいと思う唯一の部分は、「単一責任の原則」です。

私が探しているのは、これらの原則が使用されている記事または例です。そして、一部の部品を使用すべきではない理由について何か議論はありますか？

たとえば、「インターフェイス分離の原則」は、「多くのクライアント固有のインターフェイスが1つの汎用インターフェイスよりも優れているという概念」を示しています。

しかし、私の知る限り、JSにはインターフェースのようなものはありません（そうなるといいのですが）。

SOLID の原則とテスト可能性を念頭に置いて、次のケースを検討してください。

重複するプロパティを持つクラス A とクラス B があります。共通プロパティをクラス A からクラス B にコピーおよび/または変換するメソッドが必要です。そのメソッドはどこに行くのでしょうか?

1. A を B としてクラス化 GetAsB() ?
2. クラス B をコンストラクタ B (A 入力) として?
3. メソッドとしてクラス B void FillWithDataFrom(A 入力)?
4. クラス C を静的メソッドとして B ConvertAtoB(A ソース)?
5. ???