我在一个相当大的产品上工作.它一直处于开发阶段,因为.Net 1.0仍然是一个正在进行中的工作,所以它有很多质量不好的代码,并没有考虑单元测试.现在我们正在尝试提高质量并实现每个功能和错误修复的测试.我们现在遇到的最大问题之一是依赖地狱和上帝的对象.有一个上帝对象特别糟糕：会话.基本上,与该程序的当前会话相关的任何内容都在此对象中.还有一些其他神物.
无论如何,我们通过使用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上帝接口/对象
现在给你.这是对这些上帝物体进行测试并最终将其分解的好方法吗？这是一种记录在案的方法和/或设计模式吗？你做过这样的事吗？
解决方法
从我的观点来看,这是正确的方法.稍后你可以注入更多特定的服务实例作为IFoo / IBar而不是ISession,我想说这是一个很好的中间步骤,然后进一步重构从上帝类提取类到许多特定服务.
我看到一些专业人士：
第一阶段：提取接口
>超级(上帝)类类型由接口抽象
>代码变得不那么耦合,因为依赖于单功能负责的接口(服务)
>你有进一步的动作并将神级分成许多服务而没有大规模的重构sicne everythign已经依赖于接口API
第二阶段：将一个神级分成许多小型服务,并牢记Single Responsibility principle
第三阶段：结构化现有的单元测试,使测试按服务类型分组,而不是围绕神类进行分组
