Martin Fowler:继承是被误用了


很多权威人士,包括OO粉丝,都不喜欢“继承”,但是它让我将一个通用行为调整到特定行为时更有用和简单,只是它被误用了,像很多技术一样,需要学会如何好好地用它。

众说纷纭:
1. 我默认使用组合,并且如果在重复几次之后有意义时才使用继承。

2. 不幸的是,继承通常用于非业务范围,而不是使用在领域逻辑上。一个很好的例子是一些Web框架需要扩展控制器或模型类的方式。继承具有良好的用例,但它不应该是默认选项。

3. 对不起,这就像是说厨师应该默认使用钝刀,因为他们可能会用锋利的刀削减自己。

4. 当我需要一切都符合相同的契约或者部分实例化类时,我喜欢使用继承。继承的核心问题是:它只是众多类关系中的一个,但它被提升为核心语法

5. 我谦卑地建议你使用继承,会比“普通开发者”好几个数量级。默认值很重要。OOP允许默认继承,这导致在实际帮助的少数情况下更多的病态耦合。

6. 当你看到一个实现12个接口的类,每个接口只有1个方法时,你可能会开始认为组合不是银弹,继承也不是。一个设计良好的解决方案使用两者。

7. 关于继承的最危险的事情,它使得调整通用行为变得简单。易于实施,但维护成本不明确(特别是如果我们在层次结构中定期进行这些类型的更改),会分布在多个文件中。

8. 我对使用继承,接口隔离结合应用DDD模式实现的模型有很好的经验。例如,使用子域的继承使关系变得清晰(非常明确)并且非常有用。

9.不幸的是,函数性编程现在很流行,人们不明白这些东西只是工具。继承不仅仅是OO的东西。有些人认为。例如,在Clojure中有一些简洁的机制。

10. 继承意味着紧密耦合。在某些情况下这很糟糕,在其他情况下则很好。因此,我不愿在*已发布的* API中使用继承,但它经常在* private * API中具有很大的价值。我们有一个Payment类,它针对每个用例进行了扩展,但这是一个封闭的私有API。即核心应用程序的一部分。这是继承具有巨大利益的一个完美例子,但它处于受控制的环境中。

11. 在某些语言中,使用继承似乎性能更高,因为它是在编译器级别实现的,使用组合有时需要不同的实例,更多的内存,有时还会失去静态调度的好处