类设计 – 单一责任原则：一个类中的所有公共方法都必须使用所有

发布时间：2020-12-14 00:46:35 所属栏目：百科来源：网络整理

导读：说我有一个类似如下的类： internal class SomeClass{ IDependency _someDependency; ... internal string SomeFunctionality_MakesUSEOfIDependency() { ... }} 然后我想添加相关的功能,但是使用不同的依赖来实现其目的.也许像下面这样： internal class So

说我有一个类似如下的类：

internal class SomeClass
{
    IDependency _someDependency;

    ...


    internal string SomeFunctionality_MakesUSEOfIDependency()
    {
    ...
    }
}

然后我想添加相关的功能,但是使用不同的依赖来实现其目的.也许像下面这样：

internal class SomeClass
{
    IDependency _someDependency;

    IDependency2 _someDependency2;

    ...


    internal string SomeFunctionality_MakesUSEOfIDependency()
    {
    ...
    }

    internal string OtherFunctionality_MakesUSEOfIDependency2()
    {
    ...
    }
}

当我为这个新功能编写单元测试(或更新我现有功能的单元测试)时,我发现自己创建了一个新的SomeClass(SUT)实例,同时传递了一个不需要依赖的空值对于我正在寻找测试的功能的特定位.

这似乎对我来说是一种难闻的气味,但是我发现自己正在走下去的原因是因为我发现自己为每个新功能创建新课程.这似乎也是一件坏事,所以我开始尝试将类似的功能组合在一起.

我的问题是：一个类的所有依赖项是否应该被其所有功能所消耗,即如果不同的功能位使用不同的依赖关系,那么这些线索应该可能生活在不同的类中？

SomeClass是否保持内部状态,还是只是“组装”各种功能？你可以这样重写：

internal class SomeClass
{
    ...


    internal string SomeFunctionality(IDependency _someDependency)
    {
    ...
    }

    internal string OtherFunctionality(IDependency2 _someDependency2)
    {
    ...
    }
}

在这种情况下,如果SomeFunctionality和其他功能在某种程度上(功能上)相关,则使用占位符并不明显时,您可能不会中断SRP.

并且您具有能够从客户端选择要使用的依赖关系而不是在创建/ DI时间的附加值.也许有些测试定义这些方法的用例将有助于澄清这种情况：如果您可以编写一个有意义的测试用例,其中两个方法在同一个对象上被调用,那么您不会中断SRP.

对于Facade模式,我已经看到它太多了,喜欢它,你知道,当你最终得到一个50方法类…问题是：你为什么需要它？为了有效率的原因àla old-timer EJB？

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!