問題タブ [solid-principles]

SOLID の原則によれば、クラスは他のクラスに依存することはできず、依存関係を注入する必要があります。それは簡単です：

しかし、IBar の背後にある正確な実装を知らずに、Foo クラスで Bar を作成できるようにしたい場合はどうすればよいでしょうか? ここで 4 つの解決策を考えることができますが、それらにはすべて欠点があるようです。

1. オブジェクトのタイプを注入し、リフレクションを使用する
2. ジェネリックの使用
3. 「Service Locator」を使用して Resolve() メソッドを呼び出します。
4. 分離されたファクトリ クラスを作成し、それを Foo に挿入します。

最後のケースは当然のようですが、BarCreator クラスのコードが少なすぎます。では、どちらが良いと思いますか？

stackoverflow の「Open Closed Principle」については、多くの議論がなされてきました。ただし、一般的には、原則のよりリラックスした解釈が一般的であるように思われるため、たとえば Eclipse はプラグインを使用して変更できるようになっています。

厳密な OCP に従って、新しい動作を追加するためではなく、バグを修正するためだけに元のコードを変更する必要があります。

OCP を介して機能の進化を観察できる、パブリックまたは OS ライブラリで OCP の厳密な解釈の良い例はありますか?元のコードが変更されていない元のクラスが拡張された、ライブラリの次のバージョン。

編集: Robert C. Martin によると、「リンク可能なライブラリ、DLL、または Java .jar が変更されていないかどうかにかかわらず、モジュールのバイナリ実行可能バージョン」*。ライブラリが閉じられたままになっているのを見たことがありません。実際には、新しい動作がライブラリに追加され、新しいバージョンが公開されています。OCP によると、新しい動作は新しいバイナリ モジュールに属します。

*Robert C. Martin によるアジャイル ソフトウェア開発、原則、パターン、および実践

特定の SOLID 原則に直接変換される GoF 設計パターンを知りたいですか? たとえば、(私の意見では) 戦略パターンは依存関係逆転の原則に変換されると思います。

残念ながら、それらの関係を調べた文献は見つかりませんでした。お互いの視点でより効果的に両方を学ばなければならないのはいいことです.

単一責任の原則 (SRP) を学ぼうとしていますが、あるクラスからいつ、何を削除し、どこに配置/整理する必要があるかを理解するのが非常に難しいため、非常に困難です。

いくつかの資料とコード例をグーグルで探していましたが、見つけたほとんどの資料は、理解しやすくするのではなく、理解を困難にしました。

たとえば、ユーザーのリストがあり、そのリストから、ユーザーが出入りするときに挨拶とさようならのメッセージを送信する、ユーザーが入ることができるかどうかを確認するなど、多くのことを行う Control という名前のクラスがある場合彼を蹴ったり、ユーザーのコマンドやメッセージを受け取ったりします。

例から理解する必要はあまりありません.私はすでに1つのクラスにあまりにも多くのことをしていますが、後でそれを分割して再編成する方法については十分に明確ではありません.

SRP を理解していれば、チャンネルに参加するためのクラス、あいさつとさようならのためのクラス、ユーザー認証のためのクラス、コマンドを読むためのクラスが必要ですよね?

しかし、たとえば、どこでどのようにキックを使用しますか?

私は検証クラスを持っているので、天気を含むあらゆる種類のユーザー検証がそこにあると確信しています。ユーザーをキックする必要はありません。

したがって、キック関数はチャネル結合クラス内にあり、検証が失敗した場合に呼び出されますか?

例えば：

ここで、オンラインで無料のわかりやすい C# 資料を提供してくれるか、引用された例をどのように分割するか、可能であればいくつかのサンプル コード、アドバイスなどを示して、私に手を貸していただければ幸いです。

私は単純なアプリケーションを計画しており、単一の責任とカプセル化の原則に従いたいと考えています。

主なプレーヤーは次のとおりです。

API クラス- ユーザーを保存する機能を公開します。

DBConnector クラス- ユーザー データを DB に保存する機能を公開します。

User クラス- ユーザーを表します。

古い方法では、saveUser メソッドは次のようになります。

新しい原則によると、正しい方法は次のようになります。

これは正しいです？

ユーザーが DB の保存を処理する必要がありますか?

そうでない場合は、より良い方法を提供できますか?

YoutubeVideoServiceCRUD（作成、読み取り、更新、および削除）操作を行うクラスがあります。私の見解では、作成、読み取り、更新、および削除は、クラスが変更される 4 つの理由です。このクラスは単一責任の原則に違反していますか?

違反する場合はCreateYoutubeVideoService、ReadYoutubeVideoService、 、 のUpdateYoutubeVideoServiceような 4 つのクラスが必要DeleteYoutubeVideoServiceです。授業が多いのはやり過ぎじゃない？

私のチームは、アーキテクチャ戦略としてドメイン駆動設計に固執しようと懸命に努力しています。しかし、ほとんどの場合、私たちのドメイン エンティティはかなり貧弱です。ドメイン エンティティに、より多くのビジネス/ドメインの動作を追加したいと考えています。

たとえば、アクティブ レコードはエンティティにデータ アクセスを配置します。私たちは喜んでデータ アクセスにリポジトリ パターンを使用しているため、これは望ましくありません。

また、ソフトウェアを SOLID (ボブおじさんがまとめた 5 つのソフトウェア設計原則) になるように設計しています。したがって、エンティティを設計する際に、単一の責任、開閉、リスコフ、インターフェイスの分離、および依存関係の逆転に注意を払うことが重要です。

では、どのような種類の動作を含める必要がありますか? どのような種類のものを避けるべきですか?

予約、既存の予約の変更、および既存の予約のキャンセルを可能にする予約システムがあります。私はインターフェイス分離の原則を調べていましたが、インターフェイスをどれだけ薄くするべきか、単一責任の原則に違反しているかどうか疑問に思っていました。私の最初の設計は次のとおりです。

しかし、ある予約システムが予約のためにこれらのメソッドのいずれかを実装する必要がなく、たとえば予約にのみ関心がある場合はどうなるか考えたので、次のようにしました。

今、私はこのようなことができます：

また

だから問題は、このように間引いて遠くまで持っていくのかということになります。また、インターフェイスの名前を考えるのが難しくなります。たとえば、IModify や ICancel は好きではありません (これらは IReservation インターフェイスにあるはずのメソッドのように思えます)。インターフェイスに何を入れる必要があり、別のインターフェイス、クラスなどに何を分離する必要があるかをどのように判断しますか...