设计视角:静态方法与类

Question

虽然这是一个相当普遍的问题,但我正在努力解决它的最佳方法(如果在这种情况下需要接近它).

I have inherited a website (ASP.NET, C#) part of which contains a class full of static methods (it's a very large class, honestly). One method in particular is for sending e-mails. It has every possible parameter I can think of and it works well enough. However, the internals of that particular method are rather cumbersome to manage and understand due to the fact that everything is shoved inside - particularly when most of the parameters aren't used. In addition, it is somewhat difficult to handle errors, again, due to all the parameters for this one method.

Would it make more sense to actually have an EMail class which is instantiated when you want to send an e-mail? This just "feels" more right to me, though I can't full explain why. What are your thoughts on the way to go in this particular case? How about in general?

Thanks.

Answer 1

你所描述的内容听起来像是格言的一个例子,"你可以用任何语言写FORTRAN."

一个充满静态方法的大型课程通常(并不总是)表明有人没有"获得"OOP,陷入程序编程思维模式并试图扭曲语言来做他想做的事情.

根据经验:如果任何方法(静态或实例)需要超过大约5个参数,那么通常表明该方法试图同时执行太多操作,并且是重构为一个或多个类的良好候选者. .

此外,如果静态方法没有真正相关,那么它们至少应该分成实现相关功能的类.

我实际上想知道为什么你有一个"发送电子邮件"方法,因为System.Net.Mail命名空间几乎处理所有情况,并且可以通过app.config/web.config文件进行配置,所以你不需要需要传递服务器名称或端口.这是一种"通知"方法 - 单个页面应该调用的方法,以便根据填写了各种值的模板发送几条"标准"消息之一,并自动添加某些页眉/页脚？如果是这样,这种类型的交互有许多设计比你似乎继承的更容易使用.(即MailDefinition)

更新:现在看到你的评论,这是用于异常处理,我认为最合适的解决方案是一个实际的异常处理程序.这方面有大量资源.对于ASP.NET WebForms,我实际上拿了几年前Jeff Atwood写的那个,把它移植到C#并进行了一些更改(比如忽略404错误).在上一个问题中有很多好的链接.

这些天我的偏好只是将异常处理(以及随后的异常报告的电子邮件)视为日志记录的子集. log4net有一个非常强大的SmtpAppender,您可以将其配置为仅用于"致命"错误(即未处理的异常 - 在您的处理程序中,您只需LogFatal拨打电话).

重要的是,您无疑会从上面的SO链接和任何引用的链接中获取,这里实际上有两个反模式 - "杂项"静态类,并捕获您不知道如何的异常处理.这在.NET中是一种糟糕的做法 - 在大多数情况下,您应该只捕获可以从中恢复的特定于应用程序的异常,并让所有其他异常冒出来,在必要时安装全局异常处理程序.