1

これはかなり一般的な問題ですが、私はそれにアプローチするための最良の方法に苦労しています(この場合、アプローチする必要がある場合)。

私はWebサイト(ASP.NET、C#)を継承しましたが、その一部には静的メソッドでいっぱいのクラスが含まれています(正直なところ、これは非常に大きなクラスです)。特に1つの方法は、電子メールを送信することです。それは私が考えることができるすべての可能なパラメータを持っており、それは十分に機能します。ただし、その特定のメソッドの内部は、すべてが内部に押し込まれているため、特にほとんどのパラメーターが使用されていない場合は、管理と理解がかなり面倒です。さらに、この1つのメソッドのすべてのパラメーターのために、エラーを処理することはやや困難です。

電子メールを送信したいときにインスタンス化されるEMailクラスを実際に持つ方が理にかなっていますか?理由を完全に説明することはできませんが、これは私にとってより正しいと「感じる」だけです。この特定のケースに進む途中であなたはどう思いますか?一般的にはどうですか?

ありがとう。

4

5 に答える 5

5

あなたが説明していることは、「FORTRAN はどの言語でも書ける」という格言の例のように聞こえます。

静的メソッドでいっぱいの巨大なクラスは、多くの場合 (常にではありません)、誰かが単に OOP を "理解" できず、手続き型プログラミングの考え方にとらわれていて、言語をひねって自分のやりたいことをやろうとしている兆候です。

経験則として、静的またはインスタンスのいずれかのメソッドが約 5 つ以上のパラメーターを受け取る場合、多くの場合、メソッドが一度に多くのことを実行しようとしている兆候であり、1 つまたは複数のクラスにリファクタリングするのに適しています。 .

また、静的メソッドが実際には関連していない場合は、少なくとも関連する機能を実装するクラスに分割する必要があります。

System.Net.Mail名前空間がほぼすべてのケースを処理し、app.config/web.config ファイルを介して構成可能であることを考えると、なぜ「電子メールを送信する」メソッドを使用する必要があるのか​​ 疑問に思っています。サーバー名またはポートを渡す必要があります。これはおそらく「通知」メソッドですか?さまざまな値が入力され、特定のヘッダー/フッターが自動的に追加されたテンプレートに基づいて、いくつかの「標準」メッセージの1つを送信するために、個々のページが呼び出されることになっていますか? もしそうなら、このタイプのインタラクションには、あなたが継承しているように見えるものよりもはるかに扱いやすいデザインがたくさんあります. (すなわちMailDefinition )

更新:これが例外処理に使用されているというコメントを見て、最も適切な解決策は実際の例外ハンドラーだと思います。これにはたくさんのリソースがあります。ASP.NET WebForms については、実際に Jeff Atwood が何年も前に書いたものを C# に移植し、いくつかの変更を加えました (404 エラーを無視するなど)。この前の質問には、多くの適切なリンクがあります。

最近の私の好みは、例外処理 (およびその後の例外レポートの電子メール送信) をロギングのサブセットとして扱うことです。 log4netには非常に有能なSmtpAppenderがあり、「致命的な」エラー (つまり、処理されない例外 - ハンドラーでLogFatal呼び出しを行うだけ) にのみ使用するように構成できます。

上記のSOリンクと参照されているリンクから間違いなくピックアップされる重要なことは、実際にはここに2つのアンチパターンがあることです.「その他の」静的クラスと、方法がわからない例外のキャッチです。扱います。これは .NET では不適切な方法です。ほとんどの場合、回復可能なアプリケーション固有の例外のみをキャッチし、他のすべての例外をバブルアップさせ、必要に応じてグローバル例外ハンドラーをインストールする必要があります。

于 2010-01-08T18:42:14.200 に答える
4

一般に、静的型をいつ使用するかに関する Microsoft のガイドラインは次のとおりです。

私が個人的に追加するいくつかのこと:

  • 拡張メソッドを記述するには、静的型を使用する必要があります。
  • 静的型は、モックが困難/不可能であるため、単体テストを難しくする可能性があります。
  • 静的型は不変性と参照透過関数を強制するため、優れた設計になる可能性があります。したがって、不変であり、外部依存関係を持たないように設計されているものに使用してください。たとえば、System.Math
  • Singleton パターンは悪い考えだと主張する人もいます (例)。いずれにせよ、静的型をシングルトンと考えるのは間違っています。それらはそれよりもはるかに広いです。

この特定のケースには副作用 (電子メールの送信) があり、拡張メソッドは必要ないようです。したがって、静的型の有用なケースとして私が考えるものには当てはまりません。一方、オブジェクトを使用すると、電子メールをモックできるため、単体テストに役立ちます。したがって、ここで静的型は不適切であると言うのは正しいと思います。

于 2010-01-08T18:17:53.487 に答える
3

なんてこった、はい。

移植された古いクラシック ASP アプリのようです。

単一責任の原則に違反しています。そのクラスをリファクタリングできる場合。その関数にオーバーロードを使用します。

于 2010-01-08T18:13:07.880 に答える
2

これはUtils のアンチパターンの例です。

責任に応じてこれらのメソッドを分離することは常に良い考えです。Email クラスを作成することは、間違いなく Good Idea™ です。これにより、はるかに使いやすいインターフェイスが提供され、テストで電子メールをモックアウトできます。

于 2010-01-08T18:40:19.040 に答える
0

The Little Manual of API Designを参照してください。多くのパラメーターを持つコンストラクター/メソッドを使用する代わりに、最小限のコンストラクターと多数のゲッター/セッターを持つクラスの利点について説明しています。

あなたが言及したメソッドのパラメーターのほとんどは使用されていないため、より良いアプローチは、内部変数の妥当なデフォルト設定を想定する単純なコンストラクターを使用することです。セッターメソッドを使用すると、デフォルト以外の値を必要とするいくつかのパラメーター (およびそれらのパラメーターのみ) を設定できます。

于 2010-01-08T18:59:51.623 に答える