0

私は電子メールの送信を担当するオブジェクトを持っているので、を作成しEmailSender、それをに伝えてSendEmail、いくつかを渡しますEmailDetails：

string diagnostics;    

EmailSender sender = new EmailSender();
try
{
    sender.SendEmail(details);
    //sender.SendEmail(details, out diagnostics);
}
catch(Exception e)
{
    logger.log(sender.CurrentError);
}

diagnostics = sender.Diagnostics;

にoutパラメータを追加するとSendEmail、「電子メールの送信を試みる必要があり、診断データの初期化と入力も担当する」と言っているので、SOLID設計原則の観点からビジネス上の責任が追加されますか？

おそらく責任は正しい言葉ではありませんが、一方のパターンはもう一方のパターンよりも優れていますか？

4

3 に答える 3

2

あなたは単一責任の原則に違反していません-SRPは、オブジェクトがその共同作業者と話す方法を知らないはずだという意味ではありません。それはその契約の一部であり、それは当然の責任です。EmailSenderメール配信に関する診断の報告を担当していなかった場合、誰が担当しますか？

確認する必要があるのはDiagnostics、に関して適切な粒度レベルのままであることだけですEmailSender。EmailSenderは消費者に依存せず、消費者は依存するEmailSenderのでEmailSender、消費者の形式を採用するのではなく、独自のセマンティクスを消費者に課す必要があります。

于 2012-11-30T10:04:49.823 に答える
1

あなたはSOLIDの原則のいずれにも違反していません。いわゆるサムライの原則に違反しています。

すべての操作は、コントラクトを完了して有効な結果を返すか、例外をスローする必要があります。

代わりにカスタム例外を追加するよりも、失敗に関する追加の診断情報を提供したい場合。あなたとあなたのクライアントとの間の契約の一部である何かを持っているなら、あなたは出力パラメータを通してこの情報を返すことができます。

于 2012-11-29T21:17:21.280 に答える
0

コード例を見ると、AOP設計が適切かどうか疑問に思います。ポリシーインジェクションを使用して、EmailSender（およびその他のコンポーネント）への呼び出しをラップできます。

ポリシーインジェクションを使用してコールにインジェクトするラッパーは、スローされた例外をキャッチしてログに記録する役割を担うことができるため、このコード呼び出しSendEmailでそれを行う必要はありません。

ラッパーは、タイミングの監視、トレース情報の書き込みなども担当できます。推測しているだけですが、おそらくその種の情報は、Diagnosticsプロパティを使用している目的と一致します。

このように、呼び出し元は、例外の処理/ロギング、または診断情報の処理について責任を負う必要はありません。Diagnosticsさらに、EmailSenderは、自身のパフォーマンスを監視したり、プロパティを介してその情報を公開したりする責任を負う必要はありません。

また、CurrentErrorプロパティは奇妙に見えます。CurrentErrorすでに例外をキャッチしているので、プロパティにある情報を含む特定のタイプの例外をキャッチする方が適切なようです。

于 2012-11-29T21:28:34.233 に答える