继承带来了所有不可否认的好处，下面是它的一些缺点。

继承的缺点：

您不能在运行时更改从超级类继承的实现（显然是因为继承是在编译时定义的）。继承将子类暴露给其父类实现的细节，这就是为什么人们常说继承破坏了封装（从某种意义上讲，您真正需要关注的是接口而不是实现，所以通过子类重用并不总是首选的）。继承提供的紧密耦合使得子类的实现与超级类的实现紧密结合，父类实现中的任何更改都将迫使子类进行更改。子类的过度重用会使继承堆栈变得很深，也很混乱。

另一方面，通过对象获取对其他对象的引用，在运行时定义对象组合。在这种情况下，这些对象将永远无法访问彼此的受保护数据（没有封装中断），并将被迫尊重彼此的接口。在这种情况下，实现依赖性也会比继承的情况下少得多。

如果你明白其中的区别，那么解释起来就更容易了。

程序代码

这方面的一个例子是不使用类的PHP（尤其是在PHP5之前）。所有逻辑都编码在一组函数中。您可以包含包含助手函数等的其他文件，并通过在函数中传递数据来执行业务逻辑。随着应用程序的增长，这可能很难管理。PHP5试图通过提供更面向对象的设计来解决这一问题。

遗产

这鼓励使用类。继承是OO设计的三大原则之一（继承、多态性、封装）。

class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

这是工作中的继承。员工“是”个人或继承自个人。所有继承关系都是“is-a”关系。Employee还隐藏Person的Title属性，意思是Employee.Title将返回Employees的Title，而不是Person。

作文

组合比继承更受欢迎。简单地说，你应该：

class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

组成通常是“有”或“使用”关系。这里Employee类有一个Person。它不从Person继承，而是将Person对象传递给它，这就是它“有”Person的原因。

继承上的组合

现在，假设您要创建一个管理器类型，这样您就可以：

class Manager : Person, Employee {
   ...
}

但是，如果Person和Employee都声明了Title，那么这个示例会很好用？经理头衔应该返回“运营经理”还是“先生”？在合成中，这种模糊性得到了更好的处理：

Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

Manager对象由Employee和Person组成。标题行为取自雇员。这种显式组合消除了其他问题中的歧义，您将遇到更少的错误。

要从新程序员的不同角度解决这个问题：

当我们学习面向对象的编程时，继承经常很早就被教授，因此它被视为一个常见问题的简单解决方案。

我有三个类都需要一些通用功能。所以如果我编写一个基类并让它们全部继承，然后它们将所有这些都有这个功能，我只需要维护一次位置

这听起来很好，但实际上它几乎从未奏效，原因如下：

我们发现，我们希望我们的类具有其他一些功能。如果我们向类添加功能的方式是通过继承，那么我们必须决定——我们是否将其添加到现有基类中，即使不是每个从其继承的类都需要该功能？我们是否创建另一个基类？但是，已经从其他基类继承的类呢？我们发现，对于从基类继承的一个类，我们希望基类的行为稍有不同。所以现在我们回过头来修改我们的基类，可能会添加一些虚拟方法，或者更糟的是，一些代码会说，“如果我是继承的类型A，那么就这样做，但如果我是传承的类型B，那么就那样做。”这是很糟糕的，原因很多。一个是，每次我们改变基类时，我们都在有效地改变每个继承的类。所以我们真的在改变A、B、C和D类，因为我们需要在A类中有一个稍微不同的行为。尽管我们认为我们很小心，但我们可能会因为与这些类无关的原因而破坏其中一个类。我们可能知道为什么我们决定让所有这些类彼此继承，但这对其他必须维护我们代码的人来说可能没有意义。我们可能会迫使他们做出一个艰难的选择——我是做一些非常丑陋和混乱的事情来做出我需要的改变（见前面的要点），还是只是重写一堆内容。

最后，我们把代码绑在一些困难的地方，除了说：“酷，我了解了继承，现在我使用了它。”这并不意味着居高临下，因为我们都这样做了。但我们都这么做了，因为没有人告诉我们不要这样做。

当有人向我解释“喜欢组合而不是继承”时，我回想了一下每次尝试使用继承在类之间共享功能时，我都意识到大多数时候它并没有真正发挥作用。

解药是单一责任原则。将其视为约束。我的班级必须做一件事。我必须能够给我的班级起一个名字，以某种方式描述它所做的一件事。（凡事都有例外，但当我们学习时，绝对规则有时会更好。）因此，我无法编写名为ObjectBaseThatContainsVariousFunctionsNeedByDifferentClasses的基类。我所需要的任何不同的功能都必须在它自己的类中，然后需要该功能的其他类可以依赖于该类，而不是从该类继承。

在过于简化的风险下，这就是组合——组合多个类一起工作。一旦我们养成了这个习惯，我们就会发现它比使用继承更灵活、更可维护、更可测试。

继承带来了所有不可否认的好处，下面是它的一些缺点。

继承的缺点：

您不能在运行时更改从超级类继承的实现（显然是因为继承是在编译时定义的）。继承将子类暴露给其父类实现的细节，这就是为什么人们常说继承破坏了封装（从某种意义上讲，您真正需要关注的是接口而不是实现，所以通过子类重用并不总是首选的）。继承提供的紧密耦合使得子类的实现与超级类的实现紧密结合，父类实现中的任何更改都将迫使子类进行更改。子类的过度重用会使继承堆栈变得很深，也很混乱。

另一方面，通过对象获取对其他对象的引用，在运行时定义对象组合。在这种情况下，这些对象将永远无法访问彼此的受保护数据（没有封装中断），并将被迫尊重彼此的接口。在这种情况下，实现依赖性也会比继承的情况下少得多。

除了是/有一个考虑因素之外，还必须考虑对象必须经历的继承的“深度”。任何超过五或六级继承深度的内容都可能会导致意外的强制转换和装箱/拆箱问题，在这种情况下，编写对象可能是明智的。

我的经验法则是：在使用继承之前，考虑组合是否更有意义。

原因：子类化通常意味着更复杂和更紧密，即更难在不出错的情况下进行更改、维护和扩展。

Sun的Tim Boudreau给出了一个更完整、更具体的答案：

在我看来，使用继承的常见问题是：无辜的行为可能会产生意想不到的结果——这方面的经典例子是调用超类中的可重写方法构造函数，在子类实例字段初始化。在一个完美的世界里，没有人会这样做。这是不是一个完美的世界。它给子类提供了不正当的诱惑，让它们对方法调用的顺序等做出假设——这种假设往往不会如果超类可以随着时间的推移而发展，那么它是稳定的。另请参见我的烤面包机和咖啡壶类比。类变得更重了——你不一定知道你的超类在其构造函数中做了什么工作，或者它需要多少内存使用。因此，构建一些无辜的轻量级对象可以比你想象的要贵得多，如果超类进化它鼓励子类的爆炸。类加载需要时间，更多的类需要内存。在你与NetBeans规模的应用程序打交道，但在那里，我们有了真正的例如，由于第一次显示菜单触发了大量的类加载。我们通过移动到更多的声明性语法和其他技术，但这需要花费时间修复。这使得以后改变事情变得更加困难——如果你公开了一个类，那么交换超类会破坏子类-这是一个选择，一旦你公开了代码，你就结婚了所以如果你不改变你的真实功能超类，如果你使用，而不是扩展你需要的东西。例如，子类化JPanel-这通常是错误的；如果子类是在公共场所，你永远不会有机会重新审视这个决定。如果它作为JComponent getThePanel（）访问，您仍然可以这样做（提示：将组件的模型作为API公开）。对象层次结构不可缩放（或使其稍后缩放比提前规划要困难得多）-这是经典的“太多层”问题我将在下面讨论AskTheOracle模式如何解决它（尽管它可能冒犯OOP纯粹主义者）。...如果你允许继承遗产，我会怎么做带着一粒盐是：永远不显示字段，常量除外方法应为抽象方法或最终方法不从超类构造函数调用任何方法...所有这些都不适用于小型项目，而适用于大型项目私人课程比公共课程