問題タブ [single-responsibility-principle]

私は SOLID の原則をチームに紹介しましたが、チームはその原則を理解し、喜んで使用しています。

私は、これらの原則を使用するためにすでにリファクタリングされたいくつかのプロジェクトを彼らに提供しました。プロジェクト内の非常に疎結合されたクラス間の接続を確認するのに苦労している場合に私が見る最大の問題. クラス図を作成しても、接続が表示されません。私が言及している特定のプロジェクトも、実装に依存性注入と XML 構成を使用しています。ただし、これには目的があり、使用されているクラスを見つけるのがさらに難しくなります。

クラス間の関係と、それらがプロジェクト内でどのように使用されているかを視覚的に示す最良の方法は何ですか?!

編集日: 2008/10/24 20:40

UML コメントに基づいて、組み込みの Visual Studio クラス図を参照して、アプリケーションのモデルを構築しようとしました。各インターフェースの説明はできますが、それらが明確に接続されているかどうかはまだわかりません。

手順（検証、関連コンテンツの添付、フォーマット、送信）をより簡単にテスト、ログ記録、更新できる個別のクラスに分割することで、「メールの送信」コードをリファクタリングしようとしています。

この一環として、オペレーションが検証または一時的なエラー（「そのアイテムが削除された」）を発信者に通知して、ユーザーに詳細情報を要求したり、悪いニュースを伝えたりできるようにする方法を理解する必要があります。 。これがスレッドがたどるパスです（イェーイ、落書き）

それで、あなたは「リターン」、「例外」、または「コンテキスト」の間で思慮深い種類です…どれがあなたを幸せにしますか？

A.問題が発生した場合は例外をスローし、コントローラーに、正常に処理できるものと、私の「ブザー」を知っているものを分けさせます。

B.ある種のResultクラスを返し<T>、操作の結果（電子メール）とさまざまな操作の列挙された結果の両方を伝達します。

C.処理できないパラメータを示し、メソッドのシグネチャを非常に単純に保つことができるすべてのステップにコンテキストを渡します。

D.息子、あなたはこれを考えすぎています..これがあなたがやろうとしていることです：<YourSpecialJujuHere/>

ありとあらゆる貢献に感謝します、あなたは一丸となって揺れ動きます。

単一責任の原則と関心の分離の違いは何ですか？

クラスの責任を決めるのに問題があります。
私は3つのhtmlフォームを持っています：

1. フォームごとに、含まれるフォームのテキストとマーカーを含むhtmlテンプレートがあります。
2. エラーが発生した場合は、各フォームを検証する必要があります。テンプレートと（1）のフォームを、いくつかのエラーメッセージとともに再表示する必要があります。一部のフィールドのみが、さまざまなフォームに共通しています。
3. エラーがない場合は、結果メッセージをメールで送信する必要があります。フォームごとに結果メールテンプレートがあります。

この問題に適したクラススキームを決定するのは非常に難しいと思います。1つの可能性は、機能によってクラスを分離することです

• CheckFormData：フォームデータのチェック
• DisplayForm：エラーの有無にかかわらずフォームを表示します（またはこれも分離しますか？）
• EmailForm：emailform。

これについてはよくわかりません。ある特定の形式の分野に関する知識は、さまざまなクラスに分散しています。

いくつかのワークフローがあります。多分私はワークフロークラスも持っているべきです：

フォームタイプごとに（3つあることを忘れないでください）、

1. CheckForm、
2. EmailFormと
3. DisplayFormクラス。

3 * 3=9クラス+3基本クラス=12クラス。
また、適切なCheckForm-subclassとEmailForm-subclassをワークフローに挿入する必要があります。これらはすべて、同じフォームタイプである必要があります。たぶん、このためにFormWorkFlowFactoryを作成する必要があります。これにより、最大13のクラスが追加されます。

今、私はひどく間違ったことをしていると感じました。テンプレートメソッドクラスとして持っていた場合FormSubmitWorkFlow、3つのサブクラスを作成することもできますが、各サブクラスは異なる責任を混合します。

これをどのように改善できますか。また、答えをやる気にさせることができますか。つまり、どの方法で答えを導き出すことができますか。

編集：現在の唯一の答えは有用ですが、それに同意する人々からの投票を見るのはいいことです。あるいは、コミュニティからより良い解決策を聞きたいです。この答えに賛成したのは私だけです。この質問はより多くの入力を使用する可能性があるので、遠慮なく提供してください:-)

これはもっと理論的な質問です。ロギングは、ロギングを主な目的としないクラス内に存在する必要がありますか？

これは、数値の計算を実行するものすべての簡単なインターフェイスです。

これは、計算を実行し、いくつかのロギングを行うICalculationインターフェースの実装です。これは非常に実用的なアプローチだと思います。コンストラクターが計算のドメインで通常は見られないものを受け入れることを除けば、インラインロギングは間違いなく邪魔になりません。

ReallyIntenseCalculationからすべてのロギングコードを削除した後、コードには明確な単一責任のように見えるものが含まれるようになりました。

さて、ReallyIntenseCalculationの内部ログ機能を削除しました。その機能を外部化する方法をどのように見つけることができますか。デコレータパターンを入力します。

ICalculationを装飾するクラスを作成することで、ログをミックスに戻すことができますが、そうすると、ReallyIntenseCalculationのプライベートメソッド内で行われていたより詳細なログの一部が損なわれます。

ロギングデコレータを持つことのその他の考えられる長所と短所は何ですか？

私は同僚からデザインに反対されており、この場合のSRPの適用について誰が正しいかについてコンセンサスがあるかどうか疑問に思っています。

SRPは、主にクラスの責任など、設計の下位レベルの詳細に関連していると思います。抽象化のレベルが上がるにつれて、SRPは依然として適切であると思いますが、単一の責任の定義も必然的に、より高いレベルの抽象化に向かって移動します。

私の特定のケースでは、「fooを処理し、その結果を保存し、それらの結果へのアクセスを提供する」サービスは、「foo処理サブシステム」の単一責任を負っていますが、同僚はこれに同意せず、これを2〜3個の別個のものと見なしています。責任。私の場合、あなたが常に単一の責任を詳細に分解する場合、「銀行」を持つことは「お金を保持し、口座を維持し、住宅ローンを販売する...」ので、SRPの違反です。

私が現在取り組んでいるシステムでは、ドメイン ビジネス ルールと永続性制約の検証を分離することで、SRP (と思います!) に従っています。使いすぎた顧客の例を使用してみましょう。システムのビジネス ルールを満たすには、顧客が有効な郵便番号、住所、名前を持っている必要があるとします。さらに、顧客が選択したユーザー名はすべての顧客で一意である必要があるとしましょう。これは永続性制約として定義します。次の「本番環境の準備ができていない」疑似コードを検討してください。

上記で定義されたクラスは、次のようにサービス クラスに接続される場合があります。

このアプローチに関する私の主な懸念は、CustomerDao の将来の消費者が、SaveCustomer() の前に IsValidForPersistence() を呼び出すことを知っている必要があることです。そうしないと、無効なデータが永続化されます。SQL レベルでこれを防ぐために DB 制約を作成することもできますが、それは面倒なように感じます。

IsValidForPersistence() を CustomerDao.SaveCustomer() に移動する必要があるようですが、SaveCustomer() の署名をリファクタリングして、ValidationErrors クラスへの参照を含める必要があります。大規模なリファクタリングに飛び込む前に、これらの問題に対処するための一般的な/推奨されるパターンについて、他のユーザーからフィードバックを得たいと思いました。

ありがとう

フォームの検証とビジネスの検証について質問があります。ある種のフォーム検証ライブラリを使用する多くのフレームワークを目にします。いくつかの値を送信すると、ライブラリがフォームからの値を検証します。うまくいかない場合は、画面にいくつかのエラーが表示されます。すべてが計画どおりに進むと、値がドメイン オブジェクトに設定されます。ここで、値が検証されるか、より適切に言えば、(再び) 検証される必要があります。ほとんどの場合、検証ライブラリで同じ検証が行われます。この種の構造 Zend/Kohana を持つ 2 つの PHP フレームワークを知っています。

プログラミングと、Don't Repeat Yourself (DRY) や単一責任の原則(SRP) などのいくつかの原則を見ると、これは良い方法ではありません。ご覧のとおり、2回検証されます。実際の検証を行うドメイン オブジェクトを作成してみませんか。

例: ユーザー名と電子メール フォームを含むフォームが送信されます。ユーザー名フィールドと電子メール フィールドの値は、ユーザー名と電子メールの 2 つの異なるドメイン オブジェクトに入力されます。

これらのオブジェクトはデータを検証し、有効でない場合は例外をスローします。同意しますか？このアプローチについてどう思いますか？検証を実装するより良い方法はありますか? このようなものを処理する多くのフレームワーク/開発者について混乱しています。それらはすべて間違っていますか、それともポイントがありませんか?

編集：クライアント側の種類の検証も必要であることはわかっています。これは私の意見では別の球技です。これについてコメントがあり、この種のものに対処する方法がある場合は、提供してください。

アプリケーションの残りの部分を永続化テクノロジから抽象化するデータ アクセス レイヤーがあります。現在、実装は SQL サーバーですが、変更される可能性があります。とにかく、このメイン データ アクセス クラスは、テーブルが大きくなるにつれてどんどん大きくなっていることがわかります (現在、約 40 テーブル)。このデータ アクセス レイヤーのインターフェイスは、データを取得したい任意の質問です。

この背後にある実装は、適切なクエリを実行し、型付きコレクションで結果を返す基本的な SQL ストアド プロシージャです。

これはどんどん増えていきます。単一の責任の実際の中断がないため、かなり保守が容易ですが、クラスのコードは 2000 行を超えています。

したがって、問題は、特定のクラスサイズ (および実際の概念的な結合がない) により、これが分解されるかどうか、また分解される場合はどの次元または抽象化のレベルかということです。

数か月前に書いたいくつかのコードをリファクタリングしていますが、今では小さなクラス (いくつかのプロパティ、2 ～ 4 つのメソッド、1 ～ 2 つのイベント) を作成していることに気付きました。

これが本来あるべき姿ですか？それとも、これもコードの匂いですか？

つまり、クラスがその責任を果たすために多くのメソッドを必要とする場合、それはそうあるべきだと思いますが、多くの小さなクラスが特に良い習慣であるかどうかはわかりませんか?