组成和继承.
我知道它们都是适当选择的工具,上下文在组合和继承之间进行选择时非常重要.然而,关于每个的适当背景的讨论通常有点模糊; 这让我开始考虑传统OOP的独特方面是多么明显的继承和多态.
多态性允许人们同等地指定"is-a"关系以及继承.特别是,从基类继承隐式地创建该类与其子类之间的多态关系.然而,尽管可以使用纯接口实现多态,但是继承通过同时传输实现细节使多态关系复杂化.通过这种方式,继承与纯多态性完全不同.
作为一种工具,继承通过简化在无关紧要的情况下重用实现,为程序员提供与多态(通过纯接口)不同的方式.但是,在大多数情况下,超类的实现细节与子类的要求略有冲突.这就是为什么我们有"覆盖"和"成员隐藏"的原因.在这些情况下,继承所提供的实现重用是通过在级联级别的代码中验证状态更改和执行路径的额外工作来购买的:子类的完整"扁平化"实现细节分布在多个类之间,这通常意味着多个文件,其中只有部分适用于相关的子类.在处理继承时,查看该层次结构是绝对必要的,因为如果不查看超类的代码,就无法知道哪些未覆盖的细节会对您的状态进行整理或转移您的执行.
相比之下,独占使用组合可以保证您可以看到哪些状态可以通过显式实例化对象进行修改,这些对象的方法可以自行调用.真正扁平化的实现仍然没有实现(实际上甚至不可取,因为结构化编程的好处是实现细节的封装和抽象)但是你仍然可以重用代码,你只需要在一个地方查看当代码行为不端时.
我的目标是在实践中测试这些想法,避免传统继承为基于纯接口的多态性和对象组合的组合,我想知道,
有什么对象组成和接口无法实现继承吗？
编辑
在迄今为止的回复中,ewernli认为一种技术没有技术专长,而另一种技术则没有; 后来他提到了每种技术固有的不同模式和设计方法.这是有道理的.但是,这个建议让我通过询问是否专用组合和界面代替传统继承来禁止使用任何主要设计模式来改进我的问题？如果是这样,在我的情况下是不是有相同的模式？
为什么程序员开始使用状态代码？我的意思是,我想我可以想象,在文本字符串是一种昂贵的资源时,这可能会有用.WAYYY那时候.但即使我们有兆字节的内存可以使用,我们仍继续使用它们.模糊状态代码背后的错误消息或状态消息的含义有什么可能的优势？