Question

我在一个相当大的产品上工作。它一直处于开发阶段，因为.Net 1.0仍然是一个正在进行中的工作，所以它有很多质量不好的代码，并没有考虑单元测试。现在我们正在尝试提高质量并实现每个功能和错误修复的测试。我们现在遇到的最大问题之一是依赖地狱和上帝的对象。特别是有一个上帝对象是坏事：Session。基本上，与该程序的当前会话相关的任何内容都在此对象中。还有一些其他神物。

无论如何，我们通过使用Resharper从中提取界面，使这个神对象“可模仿”。然而，这仍然使测试变得困难，因为大多数时候你必须查看你编写的代码，以找出真正需要在100种不同方法和特性中嘲笑的内容。

现在就分开这个类是不可能的，因为这个类有数百个甚至数千个引用。

因为我有一个接口（几乎所有的代码都经过重构才能使用该接口），但我有一个有趣的想法。如果我使ISession接口继承自其他接口，该怎么办？

例如，如果我们有这样的事情：

interface IBar
{
  string Baz{get;set;}
}

interface IFoo
{
  string Biz{get;set;}
}

interface ISession: IFoo, IBar
{
}

通过这种方式，不必更新使用ISession的现有代码，也不必更新实际实现。但是，在我们编写和重构的新代码中，我们可以使用更细粒度的IFoo或IBar接口，但是传入一个ISession。

最终，我认为这可能更容易最终分解实际的ISession和Session上帝接口/对象

现在给你。这是对这些上帝物体进行测试并最终将其分解的好方法吗？这是一种记录在案的方法和/或设计模式吗？你做过这样的事吗？

Answer 1

从我的观点来看，这是正确的方法。稍后你可以注入更多特定的服务实例IFoo / IBar而不是ISession，我想说这是一个很好的中间步骤，然后再进一步重构从上帝类提取类到许多特定的服务。

我看到一些专业人士：

第一阶段：提取接口

超级（上帝）类类型由接口
由于依赖于单功能负责的接口（服务），代码变得更少耦合
你有进一步的动力，将一个神级分裂成许多服务而没有大规模重构sicne everythign已经依赖于接口API

第二阶段：将神级分成许多小型服务，并牢记Single Responsibility principle

第三阶段：构建现有的单元测试，使测试按服务类型分组，而不是围绕神级进行分组

分裂上帝对象的接口继承？

1 个答案: