你所描述的听起来像是格言的一个例子,“你可以用任何语言写 FORTRAN。”
一个充满静态方法的大型类通常(并不总是)表明有人只是没有“获得” OOP,陷入了过程编程的思维方式,并试图扭曲语言来做他想做的事。
经验法则:如果任何方法(静态或实例)接受超过 5 个参数,这通常表明该方法试图一次做太多事情,并且是重构为一个或多个类的良好候选者.
此外,如果静态方法不是真正相关的,那么它们至少应该被拆分为实现相关功能的类。
我实际上想知道为什么你会有一个“发送电子邮件”方法,因为System.Net.Mail
命名空间几乎可以处理所有情况,并且可以通过 app.config/web.config 文件进行配置,所以你不需要需要传递一个服务器名称或端口。这可能是一种“通知”方法 - 个别页面应该调用的东西,以便根据填充了各种值的模板发送几个“标准”消息之一,并自动添加某些页眉/页脚?如果是这样,那么对于这种类型的交互,有许多设计比您似乎继承的更容易使用。(即MailDefinition)
更新:现在看到您的评论,这被用于异常处理,我认为最合适的解决方案是实际的异常处理程序。这方面有大量的资源。对于 ASP.NET WebForms,我实际上采用了 Jeff Atwood 多年前写的那个,将它移植到 C# 并进行了一些更改(比如忽略 404 错误)。上一个问题中有许多很好的链接。
这些天我的偏好只是将异常处理(以及随后的异常报告的电子邮件)视为日志记录的一个子集。 log4net有一个非常强大的SmtpAppender,您可以将其配置为仅用于“致命”错误(即未处理的异常 - 在您的处理程序中,您只需LogFatal
拨打电话)。
重要的是,您无疑会从上面的 SO 链接和任何引用的链接中了解到,这里实际上有两个反模式——“杂项”静态类,以及捕获您不知道如何处理的异常处理。这在 .NET 中是一种不好的做法——在大多数情况下,您应该只捕获可以从中恢复的特定于应用程序的异常,并让所有其他异常冒泡,必要时安装全局异常处理程序。