- 相关推荐
java的继承与组合的区别
Java是一门面向对象的编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。下面是小编精心整理的java的继承与组合的区别，仅供参考，大家一起来看看吧。
继承和组合的概念：
在新类里简单地创建原有类的对象。我们把这种方法叫作“组合”，因为新类由现有类的对象合并而成。我们只是简单地重复利用代码的功能，而不是采用它的形式。
第二种方法是创建一个新类，将其作为现有类的一个“类型”。我们可以原样采取现有类的形式，并在其中加入新代码，同时不会对现有的类产生影响。这种魔术般的行为叫作“继承”(Inheritance)，涉及的大多数工作都是由编译器完成的。对于面向对象的程序设计，“继承”是最重要的基础概念之一。对于组合和继承这两种方法，大多数语法和行为都是类似的(因为它们都要根据现有的类型生成新类型)。
使用场合：
组合：各部件之间没什么关系，只需要组合即可。like组装电脑，需要new CPU(),new RAM(),new Disk()……
演示代码如下：
public class Computer {
public Computer() {
CPU cpu=new CPU();
RAM ram=new RAM();
Disk disk=new Disk();
}
}
class CPU{ }
class RAM{ }
class Disk{ }
继承：子类需要具有父类的功能，各子类之间有所差异。like Shape类作为基类，子类有Rectangle，CirCle，Triangle……
演示代码如下：
class Shape {
public void draw() {
System.out.println("draw a shape");
}
public void erase() {
System.out.println("erase");
}
}
class Square extends Shape {
@Override
public void draw() {
System.out.println("draw a Square");
}
public static void main(String[] args) {
Square s = new Square();
s.draw();
s.erase();
}
}
相比于组合，继承有以下优点：
1、在继承中，子类自动继承父类的非私有成员(default类型视是否同包而定)，在需要时，可选择直接使用或重写。
2、在继承中，创建子类对象时，无需创建父类对象，因为系统会自动完成;而在组合中，创建组合类的对象时，通常需要创建其所使用的所有类的对象。
组合的优点：
1、在组合中，组合类与调用类之间低耦合;而在继承中子类与父类高耦合。
2、可动态组合。
相关资料：
虽然继承是OOP的一大特性，但很多时候并不推荐使用，因为它常常容易使结构复杂化，容易出错。因此，除非我们确信使用继承会使程序效率最高，否则，不考虑使用它。
当Java 1.5引入注解，企业开发者对简化EJB和其他企业产品开发抱有很大期望。可以看一看同一时期的一篇文章用EJB 3.0简化企业Java开发。
然而从那时起，Java企业使用注解出现一些无法预料的后果和副作用，一些甚至到今天都没有被注意到。幸运的是，并非所有的副作用都没有被注意到，来看一些例子，在StackOverflow标题为“Why Java Annotations?”有很多有价值的评论，“Are Annotations Bad?”这篇文章有很棒的观点，还有“Magics Is Evil”，“Annotations…Good, Bad or Worse?”。
java-programmer，并非所有的注解都相同：
尽管上面许多讨论都包含有价值的观点，但并不是所有注解都是相同的。
这里有两类注解，区别在于他们是否在运行期影响程序。首先，说一下无害的一类，它们并不会在运行期对代码产生任何影响；另一种是有害的一类，它们会修改运行期行为。无害的注解包括@Deprecated, @Override, @SuppressWarnings, 等等。有害的注解包括@Entity, @Table, @PostConstruct, @ApplicationScoped,等等。
在无害的注解中存在一小部分注解，它们非常实用。有一些提供在编译期间(静态检查)捕获错误或提供安全保障。一些实用的注解包括：@Override, @NonNull/@Nullable 来自(Checker Framework), 等等。
为什么有害的注解不好？我们定义了一些有害的注解，为什么要避免使用它们呢？
想象一个标准的Java Data类拥有@PostConstruct方法。这个注解表示所标注的方法应该在对象创建好之后被调用。这个功能并不是由JVM处理，所以Date类隐式获取未知的框架和容器，而自身语义上并没有做任何事情。如果这些代码并不运行在任何容器中，而只是运行在JVM中呢？这个注解大大降低了这个类的重用性。另外对于任何使用Date的地方进行单元测试就变成了噩梦，因为你必须确保每次都正确绑定post-construction，要模拟一个兼容的容器。这就有点可笑了，一个Date类需要一个容器来运行，但这确实是有害的注解对类、方法和参数的影响。
无可否认，业务逻辑往往复杂，需要更多依赖和关系，而不仅仅是一个简单的Date类。然而没有理由在一个类中显式或隐式地添加不必要的依赖或约束，有害的注解就是：依赖和约束。
企业陷阱
不幸的是有害的声明在Java Enterprise 5大规模合法化。为了更正早期企业API的易用性问题，注解用来隐藏系统中冗余的和难用的部分。新的JEE 5被称赞为”轻量级”和”简单”，表面上看起来是这样。但是一个微小的，同时也是至关重要的误用蔓延开来。
@Statelesspublic class DocumentRepository { public Document getDocument(String title) {
...
}
...
}
如果想要获取一个Stateless EJB，“只需要”在类上声明@Stateless注解。确实，编写这个类只需要只一点动作，但是请注意这个类中有害的注解绑定了几百页的说明文档，而且只能在百万字节的应用服务器(Application Server)上运行。这又怎么能称的上是”轻量级”呢。所以，这个注解仅仅是真正需要编写的Java代码的占位符而已，代码仍需要以某种形式存在。现在只不过是隐藏在注解之下。
不幸的是，这种变通方案称为一种模式，现在有害的注解广泛分布：JPA, CDI, Common Annotations, JAXB 等等。
有害的注解有时会出现在错误的地点
因为注解通常作为开发环境，有时有害的注解被当做单一职责原则(Single Responsibility Principle)或关注点分离(Separation of Concerns)的最佳实践。
让我们来考虑一下下面这个CDI例子：
@ApplicationScopedpublic class DocumentFormatter {
...
}
上面的注解描述这个类应该是一个CDI Bean，意味着它应该只能由CDI实例化，并确保每个应用中只有一个实例。
这些信息并不属于这个类。这个服务在功能上(无论什么方式)并不会对它在当前应用中的作用产生影响。这里有两个明显的关注点。
一个JPA的简单例子：
@Entity@Table("PERSON")public class Person {
...
}
问题在于这种类往往是”领域对象(domain objects)”，它们直接将领域模型持久化。更糟的是，数据传送对象(DTO)用来在对象之间传送数据，使得整个构造变得脆弱，因为对象间耦合过于紧密。不管怎样，这是一种错误的方式。
所有的这些附加的功能和(或)信息应该从这些类中分离出来，但是它们却悄悄混在一起，因为它们”只不过”是注解。
有害的注解有时蔓延
注解有时会传染其他对象。回顾上面那个CDI Bean。每个使用它的对象，每个依赖它的对象现在都拥有一个CDI注解，否则依赖关系树就不会构建成功。
@Entity注解也一样。因为对象之间的关系，其他对象也通过注解持久化，很快所有的持久化对象都会有这个注解。我们无法使用原生的第三方对象(除非序列化或包装它们),我们无法使用其他持久化机制(比如用NoSQL DB存放对象)。
这些注解使得这些对象无法复用。它们只能在一个严格的、受控制的、不透明的环境中使用，不能和任何东西整合。
有什么替代品？
是XML吗？当然不是，至少对于上面的例子来说不是。
Spring框架使用配置来管理对象，因此可以用XML当做配置文件。然而，是否某个依赖需要在运行期改变，而不通过重新编译？如果不需要，那么很难说配置应该用另一门语言来表示，尤其重构困难、测试困难、管理需要特殊工具。
真正的替代品当然是好的Java代码，正确封装并解耦的。是的，用代码来管理对象，尽管有时被当做样板(boilerplate)，但并不算糟糕。它带来一些好处，比如让代码可读、可调试、可重构。只有那些长片的、复杂的、冗余的样板是糟糕的，比如“关于EJB 2.0”。但是解决方案并不是摆脱所有的样板或用另一种语言隐藏样板，而是简单干净的架构，直接而不多余的信息，简单并合适的方式来面向对象。
这也适用于JPA、Spring和其他东西。误用注解来表示功能会发生Stcakoverflow上这个问题“Arguments Against Annotations”，为什么不用已有的工具呢：比如Java语言本身和编译器，来解决这类问题，面向对象和软件最佳实践。
如果注解在代码运行期加上了额外功能和约束，那它是有害的。这很糟糕，因为它隐藏了类或方法的切面，使之难懂、难复用、难重构、难测试。
不幸的是Java Enterprise不理睬Java开发者社区中发对注解的声音。所以企业级Java和其他”官方”框架更不可能重视这类问题。
至少我们可以持续关注有害的注解，如果可能尽量避免使用，编写新的框架和软件替换掉注解，不会出现有害注解所带来的问题。
【java的继承与组合的区别】相关文章：
JavaScript与Java的区别11-26
java继承抽象类03-27
C语言与JAVA的区别12-04
Java中定义与声明的区别03-19
C语言与JAVA理论区别03-19
Java与C/C++的区别06-18
java - public class与class的区别详解04-03
浅析Java程序与C语言的区别03-01