在业务处的一个构成部分中,如果某个类别只有一个执行单位,而这一类别没有向其他构成部分公布,那么与接口和工作是否可取?
我完全了解将方案拟定到接口设计原则,并广泛使用。
近来,我一直指出,几乎不需要大部分时间不同的执行(尽管可能而且会有意义)。 由于总是与接口合作,因此,应用法将具有相当数量的接口,每个版本只有一次实施,接口似乎是一种间接费用。
相反,最好是与具体类别合作,只在需要第二次执行时才引入接口? 不管怎么说,现在利用民主选举学会提取接口是一种缩略语。 当引入新的接口时,可以改用旧的具体类别,而不是使用新的接口。
你认为什么?
据我所知,有三个情况需要接口:
Don t be afraid to use concrete classes. Don t mechanically generate an interface for every single class.
我之所以继续安排一个接口,即使只有一个执行,原因是它使编写我的测试文件的工作更加容易。 我可以建立轴心,以检验我想要测试的任何东西,我不必担心激烈的政变。
这并不总是可取的,但它在你重新努力作出决定时值得思考。 你们是否认为有必要对这一类/目标进行广泛测试? 如果你认为,与具体类别相比,与接口打交道会非常容易。
除此以外,别的办法是不使用接口,将具体类别分门别类,后者也运作起来,但又取决于它。
为具体类型建立接口是一种微妙的平衡行为,因为你能够轻松地制造交错爆炸,不带来好处,只会使领域空间与多余的类型复杂化。
我的行程规则是,只为属于公益物一部分的类型建立接口。 专门用于实施APIC并从未接触过的所有类型不需要接口。
除了已经提供的良好答案外(测试和公益物的停止) 我喜欢使用接口,因为这样可以更容易地把注意力集中在“什么”你的班子上,而不是“如何”他们这样做。
Generally: No. You don t need an interface if you re just implenting the functionality once. Interfaces like everything have a tradeoff: they introduce some more work (cost), and might introduce some more benefit. If the cost outweighs the benefit, you probably shouldn t do it!
