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

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

第二阶段:拆分神级为许多小的服务,保持单一职责原则记

第三阶段:结构化现有的单元测试,使测试按服务类型分组,而不是围绕神类进行分组