問題タブ [solid-principles]

この質問は言語に依存しませんが、私は C# 派なので、POCO という用語を使用して、通常はゲッター フィールドとセッター フィールドを使用して、データ ストレージのみを実行するオブジェクトを意味します。

ドメイン モデルを作り直して超強力な POCO にしましたが、プロパティ値がドメイン内で意味をなすようにする方法に関していくつかの懸念が残っています。

たとえば、サービスの EndDate は、サービスが下にある契約の EndDate を超えてはなりません。ただし、チェックを Service.EndDate セッターに入れるのは SOLID 違反のように思えます。実行する必要がある検証の数が増えると、私の POCO クラスが雑然とすることは言うまでもありません。

私にはいくつかの解決策があります（回答に投稿します）が、それらには欠点があり、このジレンマを解決するためのお気に入りのアプローチは何ですか?

私は SOLID デザイン原則のプレゼンテーションを行っており、単一責任原則とオープンクローズ原則をデザイン パターンに結びつけようとしています。

現在、私は持っています

• SRP:プロキシ、ファサード
• OCP:戦略、コマンド

含める必要がある他の基本的なパターンはありますか?

オブジェクトを「単一の責任」に分解する場合、同様のオブジェクトが一緒に存在するか、個別に存在するかについての基本的な考えはありますか?たとえば、私が持っている場合

これらすべてが内部に存在し、インターフェースを介して疎結合されているのは悪臭ですか?所有する Employee クラス:

それとも、コード内でこれらのクラスを完全に分離する (または少なくとも可能な限り分離する) ことを中心に考えていますか? それとも、これらの方法は両方とも SRP の有効な使用法ですか?

編集:例で与えられたオブジェクトの実現可能性について批判したくありません。質問を説明するために作成しただけです。データ、休暇、給与処理は従業員クラスのドメインではないことに同意します。

ただし、SRP は、現実世界の表現としてのオブジェクトから離れて、単一の機能概念に関するプロパティおよびメソッドとしてのオブジェクトに移動するように私に求めているようです。

オブジェクト「Customer」に関する Word ベースのレポートを生成する必要があるという問題があります。

私は通常、Word 文書の作成方法やブックマークの挿入方法を知っているクラスに Customer を渡すことでこれを行います。

これに関する問題は、Customer オブジェクトに関する情報を取得してフォーマットするためのロジックをこのクラスに配置していることに気付くことです。

これは悪いことであり、単一責任の原則に違反していることは理解しています。

カスタムを受け入れ、データの書式設定と取得に関するすべてのロジックを備えた「CustomerReportInfo」のような別のクラスを作成することについて考えました。そのようにして、Word 生成クラスは小さく、2 つのクラスは互いに関係なく変更できます。

このクラスを何と呼ぶべきか疑問に思っています。パターンのリストを調べましたが、説明に適合するものは何も見つかりません。戦略やプロキシのようには聞こえません... DTO のように聞こえますが、DTO は通常、機能のないダム クラスですよね。

これがどのパターンに似ているかについてのアイデアはありますか?

基本的に、実際のコードで単一責任の原則を使用することが合理的であると考える人の割合と、実際に使用する人の数を把握したいと思います。ポッドキャスト＃38で、ジョエルはこのOOPの原則が現実の世界でどれほど役に立たないかについて語っています。さらに、これは、ボブおじさんのような人々が重要なシステムを作成していない可能性が高いことを示しています。

私はいくつかのソフトウェアプロジェクトで個人的に書いたり、大きな役割を果たしたりしましたが、若いキャリアの中でこのパターンに出くわしたのは今だけです。私はこの原理の音が大好きで、本当に使い始めたいと思っています。私はポッドキャストでのジョエルの議論が非常に弱いことに気づきました（ここでブログのコメントを読み続けると他の人もそうしました）。しかし、それに真実はありますか？

コミュニティはどう思いますか？

私は常に、Linq2SQL クエリをあらゆる場所に、ほぼすべてのクラスに挿入してきました。

Linq2SQL クエリをどこに配置するかについて、あなたの戦略を知りたいですか?

それらを別々のデータレイヤークラスに配置しますか、それともどこでも使用される場所に保存しますか?

Linq2SQL クエリの戦略を変更し、それらを別の DataLayer クラスに格納する必要があると思います。TDD を効率的に実行し、Dependency Injection と Solid の原則に準拠するには、必須だと思います。

これが重複していないことを願っています...

あなたが遭遇した中で最もしっかりと設計され実装されたソフトウェアシステム/フレームワーク/アプリケーションは何ですか？

TDD、SOLIDの原則、オブジェクト指向のデザインパターンなどは、ポッドキャストやブログで非常に簡単な例を使用して簡単に理論化できるようですが、コードを爆発させることなく、これらの標準に完全に準拠した大規模なシステムを開発することは想像できません。 。私の会社では、完全なTDDを実行することは、時間の制約があるため、ほとんど問題外のようです。

誰かが私に良いオープンソースプロジェクトを教えてくれるなら、私は本当に掘り下げて、どんな良いTDD/SOLIDなどを見てみたいと思います。のように見えます。ありがとう。

以前にも似たような質問をして、良い回答がいくつかありましたが、一般的すぎたように思います。

優れたソフトウェア設計と実装の例

本当に優れた TDD プラクティスと SOLID 原則を示すオープンソース プロジェクトを知っている人はいますか? TDD と SOLID は広く公表されていますが、実際に自分で行ったのを見たことがありません。プロジェクト (大規模または小規模) でどのように見えるかを知りたいですか?

確固たる原則が実際のプロジェクトでどのように正しく活用されているかを知りたい/学びたい.

それともありませんか？