相关疑难解决方法(0)

为什么喜欢构图而不是继承呢？每种方法都有哪些权衡取舍？什么时候应该选择继承而不是作文？

背景:

作为Java程序员,我从接口广泛继承(而不是:实现),有时我设计抽象基类.但是,我从来没有真正觉得需要子类化一个具体的(非抽象)类(在我这样做的情况下,后来发现另一个解决方案,例如委托会更好).

所以现在我开始觉得几乎没有从具体类继承的合适的情况.一方面,Liskov替换原则(LSP)似乎几乎不可能满足非平凡类; 还有许多其他问题,这里似乎呼应了类似的意见.

所以我的问题:

在哪种情况下(如果有的话)从具体类继承它真的有意义吗？你能给出一个继承自另一个具体类的类的具体的,真实的例子吗？你觉得这是给定约束的最佳设计吗？我对满足LSP的示例(或满足LSP似乎不重要的示例)特别感兴趣.

我主要有Java背景,但我对任何语言的例子感兴趣.

我必须承认我有点像OOP怀疑论者.面向对象的不良教学和实验经验无济于事.所以我转变成了Visual Basic中的狂热信徒(经典之作!).

然后有一天我发现C++已经改变了,现在有了STL和模板.我真的很喜欢!使语言有用.然后另一天MS决定对VB进行面部手术,我真的很讨厌无端更改的最终结果(使用"end while"而不是"wend"会让我成为一个更好的开发者？为什么不放下"next"for"结束了",为什么呢？为什么强迫getter和setter一起？等等？加上我发现无用的Java特性(例如继承,以及分层框架的概念).

现在,几年后,我发现自己在问这个哲学问题:遗产真的需要吗？

四人一组说我们应该支持对象组合而不是继承.在考虑它之后,我找不到你可以用继承做的事情,你不能用对象聚合和接口做.所以我想知道,为什么我们甚至在第一时间拥有它？

有任何想法吗？我很想看到一个例子,说明继承器肯定需要在哪里,或者使用继承而不是组合+接口可以导致更简单和更容易修改的设计.在以前的工作中,我发现如果你需要更改基类,你还需要修改几乎所有的派生类,因为它们取决于父行为.如果你使基类'方法虚拟...那么没有太多的代码共享发生:(

另外,当我最终创建自己的编程语言(我发现大多数开发人员共享的长期未满足的愿望)时,我认为添加继承没有任何意义......

组成和继承.

我知道它们都是适当选择的工具,上下文在组合和继承之间进行选择时非常重要.然而,关于每个的适当背景的讨论通常有点模糊; 这让我开始考虑传统OOP的独特方面是多么明显的继承和多态.

多态性允许人们同等地指定"is-a"关系以及继承.特别是,从基类继承隐式地创建该类与其子类之间的多态关系.然而,尽管可以使用纯接口实现多态,但是继承通过同时传输实现细节使多态关系复杂化.通过这种方式,继承与纯多态性完全不同.

作为一种工具,继承通过简化在无关紧要的情况下重用实现,为程序员提供与多态(通过纯接口)不同的方式.但是,在大多数情况下,超类的实现细节与子类的要求略有冲突.这就是为什么我们有"覆盖"和"成员隐藏"的原因.在这些情况下,继承所提供的实现重用是通过在级联级别的代码中验证状态更改和执行路径的额外工作来购买的:子类的完整"扁平化"实现细节分布在多个类之间,这通常意味着多个文件,其中只有部分适用于相关的子类.在处理继承时,查看该层次结构是绝对必要的,因为如果不查看超类的代码,就无法知道哪些未覆盖的细节会对您的状态进行整理或转移您的执行.

相比之下,独占使用组合可以保证您可以看到哪些状态可以通过显式实例化对象进行修改,这些对象的方法可以自行调用.真正扁平化的实现仍然没有实现(实际上甚至不可取,因为结构化编程的好处是实现细节的封装和抽象)但是你仍然可以重用代码,你只需要在一个地方查看当代码行为不端时.

我的目标是在实践中测试这些想法,避免传统继承为基于纯接口的多态性和对象组合的组合,我想知道,

有什么对象组成和接口无法实现继承吗？

编辑

在迄今为止的回复中,ewernli认为一种技术没有技术专长,而另一种技术则没有; 后来他提到了每种技术固有的不同模式和设计方法.这是有道理的.但是,这个建议让我通过询问是否专用组合和界面代替传统继承来禁止使用任何主要设计模式来改进我的问题？如果是这样,在我的情况下是不是有相同的模式？

这个问题不是 "遗产与构成"之类的问题.

我完全理解继承与组合有什么不同,我知道Liskov替换原理,钻石问题,它们的优点和缺点以及这两个概念似乎都很简单.但到处都有关于继承和构成的问题,我想,也许我误解了这个简单的想法.

让我们关注Go.Go是一种来自谷歌的语言,每个人都很兴奋它没有继承,它没有类,但它有组成,这很酷.对我来说,Go中的组合为您提供与其他语言(C++,Java,...)中的继承完全相同的功能 - 组件方法会自动公开并作为后续结构的方法提供,如下所示:

package main

import (
    "fmt"
)

type Car struct{
    name string
}

func (c *Car) move() bool { 
    return true
} 

type MyCar struct{
    Car   
}

func main() {
    var c MyCar
    fmt.Print(c.move())
}

所以总结一下,组合比继承更好,因为:

1. 更灵活(允许您在运行时更改组件,因此您可以影响"类"的工作方式.
2. 没有钻石问题(但钻石问题是可以解决的,所以这不是强大的优势)

如果您考虑Go及其接口(每个对象,具有接口定义的方法,实现此接口隐含),您是否拥有最终解决方案？我们可以说含有一些语法糖的成分可以代替遗传吗？

这种设计符合Liskov替代原则.我是否会遗漏某些内容或继承(从任何语言中获知)与Go中已知的组合(和接口)相比没有优势？

===== edit1 =====

为了澄清,可以Go使用"标准"组合机制,就像这样(这个例子的行为与前一个一样):

package main

import (
    "fmt"
)

type Car struct{
    name string
}

func (c *Car) move() bool { 
    return true …

要旨

有利于继承而不是mixins的原因是什么

给出以下伪代码示例:

class Employee

class FullTimeEmployee inherits Employee

class PartTimeEmployee inherits Employee

// versus

class Employee

class WorksPartTime

class WorksFullTime

class FullTimeEmployee includes Employee, WorksFullTime
class PartTimeEmployee includes Employee, WorksPartTime

如果我们使用继承来构建对象,则类关系将被视为树,与mixin一样,类关系将被视为平面列表.

假设我们使用的语言

• 允许mixin使用非详细语法
• 允许我们透明地对待FullTimeEmployeea Employee和FullTime对象.

我们为什么要建立我们的类关系作为树(继承)而不是平面列表(组合)？

树与列表的示例.

class Person

class Employee inherits Person

class FullTimeEmployee inherits Employee

//                      -> FullTimeEmployee
//  Person -> Employee
//                      -> PartTimeEmployee

class Person

class Employee includes Person

class FullTime

class FullTimeEmployee includes FullTime, Employee

//
// FullTimeEmployee = …