7

我在一个相当大的产品上工作。它一直在开发中，因为 .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 上帝接口/对象

现在给你。这是测试这些上帝对象并最终分解它们的好方法吗？这是记录在案的方法和/或设计模式吗？你做过这样的事吗？

4

1 回答 1

6

从我的角度来看，这是一种很好且正确的方法。稍后您可以将更具体的服务实例注入为IFoo/IBar而不是ISession，我会说这是一个很好的中间步骤，然后进一步重构以将类从上帝类提取到许多特定服务。

我看到的一些优点：

第一阶段：提取接口

  • 一个超（神）类类型被接口抽象出来
  • 由于依赖于单一功能的负责接口（服务），因此代码的耦合度降低了
  • 您有进一步的基础，将一个神类拆分为许多服务，而无需大规模重构，因为一切都已经依赖于接口 API

第二阶段：将一个神类拆分为多个小服务，同时牢记单一职责原则

第三阶段：将现有的单元测试结构化，使测试按服务类型分组，而不是围绕一个上帝类一起进行

于 2013-02-08T15:26:19.627 回答