c# – 实用类..好还是坏？

我一直在阅读,通过在代码中使用静态类/单例来创建依赖关系,是错误的形式,并创建问题.紧耦合和单元测试.

我有一个情况,我有一组url解析方法没有状态与它们相关联,并且只使用方法的输入参数执行操作.我相信你熟悉这种方法.

在过去,我将继续创建一个类并添加这些方法,并直接从我的代码中调用它们.

UrlParser.ParseUrl(url);

但是等一下,那就是引入一个依赖关系到另一个类.我不确定这些“实用程序”类是否是坏的,因为它们是无状态的,并且这最小化了所述静态类和单例的一些问题.有人可以澄清一下吗

我应该将方法移动到调用类,即只有调用类将使用该方法.这可能违反了“单一责任原则”.

解决方法

从理论设计的角度来看,我觉得实用类是可以避免的事情.它们基本上与静态类没有什么不同(虽然稍微更好一点,因为它们没有状态).

但从实际的角度来看,我确实创造了这些,并在适当的时候鼓励他们的使用.尝试避免实用程序类通常很麻烦,并导致较少可维护的代码.但是,我尽量鼓励我的开发人员尽可能避免在公共API中使用这些API.

例如,在你的情况下,我觉得UrlParser.ParseUrl(…)可能更好地作为一个类来处理.看看BCL中的System.Uri – 这样可以处理一个干净,易于使用的统一资源标识符界面,可以很好地保持实际状态.我更喜欢这种方法来处理字符串,并强制用户传递一个字符串,记住验证它等等的实用程序方法.

原文地址：https://www.jb51.cc/csharp/96631.html