あなたが説明していることは、「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 では不適切な方法です。ほとんどの場合、回復可能なアプリケーション固有の例外のみをキャッチし、他のすべての例外をバブルアップさせ、必要に応じてグローバル例外ハンドラーをインストールする必要があります。