我一直在阅读,通过在代码中使用静态类/单例来创建依赖关系,是错误的形式,并创建问题.紧耦合和单元测试.
我有一个情况,我有一组url解析方法没有状态与它们相关联,并且只使用方法的输入参数执行操作.我相信你熟悉这种方法.
在过去,我将继续创建一个类并添加这些方法,并直接从我的代码中调用它们.
UrlParser.ParseUrl(url);
但是等一下,那就是引入一个依赖关系到另一个类.我不确定这些“实用程序”类是否是坏的,因为它们是无状态的,并且这最小化了所述静态类和单例的一些问题.有人可以澄清一下吗
解决方法
从理论设计的角度来看,我觉得实用类是可以避免的事情.它们基本上与静态类没有什么不同(虽然稍微更好一点,因为它们没有状态).
但从实际的角度来看,我确实创造了这些,并在适当的时候鼓励他们的使用.尝试避免实用程序类通常很麻烦,并导致较少可维护的代码.但是,我尽量鼓励我的开发人员尽可能避免在公共API中使用这些API.
例如,在你的情况下,我觉得UrlParser.ParseUrl(…)可能更好地作为一个类来处理.看看BCL中的System.Uri – 这样可以处理一个干净,易于使用的统一资源标识符界面,可以很好地保持实际状态.我更喜欢这种方法来处理字符串,并强制用户传递一个字符串,记住验证它等等的实用程序方法.