设计模式中类与类之间的关系

在设计模式中类与类之间的关系主要有6种：依赖、关联、聚合、组合、继承、实现，它们之间的耦合度依次增加。

一、继承关系       继承是一种“is-a”关系。 继承指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力。在Java中继承关系通过关键字extends明确标识，在设计时一般没有争议性。在UML类图设计中，继承用一条带空心三角箭头的实线表示，从子类指向父类，或者子接口指向父接口，是类和类之间存在父子关系。

二、实现关系       实现指的是一个class类实现interface接口（可以是多个）的功能，实现是类与接口之间最常见的关系。在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性。在UML类图设计中，实现用一条带空心三角箭头的虚线表示，从类指向实现的接口。 一个类实现一个或多个接口的方法，接口定义好操作的集合，由实现类去完成接口的具体操作

三、依赖关系       简单的理解，依赖就是一个类A使用到了另一个类B， 对于两个相对独立的对象，当一个对象依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。 而这种使用关系是具有偶然性的、临时性的、非常弱的，但是类B的变化会影响到类A。比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖。表现在代码层面，为类B作为参数被类A在某个method方法中使用。在UML类图设计中，依赖关系用由类A指向类B的带箭头虚线表示。 依赖关系是五种关系中耦合最小的一种关系。 一个类是另一个类的方法局部变量，方法的参数或方法返回值。 依赖是指类之间的调用关系，在UML中用带虚线的箭头表示。如果类A访问类B的属性或方法或者类A负责实例化类B则类A依赖类B，无须在类A中定义类B类型属性

四、关联关系    关联体现的是两个类之间语义级别的一种强依赖关系，这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的。关联可以是单向、双向的。表现在代码层面，为被关联类B以类的属性形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量。在UML类图设计中，关联关系用由关联类A指向被关联类B的带箭头实线表示，在关联的两端可以标注关联双方的角色和多重性标记。  对于两个相对独立的对象，当一个对象与另一个对象有种某种对应关系，这两个对象之间为关联关系，比如老师和学生。关联分为单向关联，双向关联和自身关联，实现方法一般是A中包含B的某个指针或者引用。类A与类B的实例之间存在特定的对应关系，在UML中用带实线的箭头表示。如果类A与类B关联，类A含有B的属性

按照类之间的数量对比，关联可以分为3种：

a.一对一关联

b.一对多关联

c.多对多关联

按方向分关联可以分为2种：

a.单向关联

b.双向关联

五、聚合关系       即has-a的关系， 聚合是关联关系的一种特例，它体现的是整体与部分的关系，即has-a的关系。此时整体与部分之间是可分离的，它们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享。比如计算机与CPU、公司与员工的关系等。表现在代码层面，和关联关系是一致的，只能从语义级别来区分。在UML类图设计中，聚合关系以空心菱形加实线箭头表示。  一个类是另一个类的属性，是整体和部分的关系。 聚合是关联关系的一种，耦合度比关联关系强，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是平等关系， 不同于关联关系的平等地位，聚合关系中两个类的地位是不平等， 而对象之间存在着包容关系，他们之间是“整体-个体”的相互关系。 普通的关联关系中，a类和b类没有必然的联系，而聚合中，需要b类是a类的一部分，是一种”has-a“的关系，即 a has-a b;。但是，has 不是 must has，a可以有b，也可以没有。a是整体，b是部分，整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享。

聚合可分为2种类型：

  a.被聚集的子系统允许被拆卸或替换，这是普通聚集关系，在UML中用带实线的空心菱形箭头表示

  b.被聚集的子系统不允许被拆卸或替换，这是强聚集关系，在UML中用带实线的实心菱形箭头表示，不可以通过set方法更换组件

六、组合关系       体现的是一种contains-a的关系 ，组合也是关联关系的一种特例，这种关系比聚合更强，也称为强聚合。它同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束，比如人和人的大脑。表现在代码层面，和关联关系是一致的， 只看代码，你是无法区分关联，聚合和组合的，具体是哪一种关系，只能从语义级别来区分。 在UML类图设计中，组合关系以实心菱形加实线箭头表示。 一个类是另一个类的属性，是整体不可分割的一部分，是强聚合。 组合是耦合度比聚合还强的一直关系，类和类之间的关系是“整体-部分”的关系，整体和部分具有相同的生命周期，部分不能脱离整体而独立存在，比如：人和身体，身体是人的一部分，不能独立存在。代码实现为A中包含B的成员变量。

区分依赖、关联和聚集：

1.依赖的特征：两个相对独立的系统，当一个系统负责构造另一个系统的实例或者依赖另一个系统的服务时，两个系统之间的关系体现为依赖。

2.关联的特征：两个相对独立的系统，当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时，两个系统之间为关联关系。

3.聚合的特征：当系统A被加入系统B中成为系统B的组成部分，系统B和系统A之间为聚集关系，聚集整体对象会制约组成对象的生命周期。

七、总结      

对于继承、实现这两种关系没多少疑问，它们体现的是一种类和类、或者类与接口间的纵向关系。其他的四种关系体现的是类和类、或者类与接口间的引用、横向关系，是比较难区分的，有很多事物间的关系要想准确定位是很难的。前面也提到，这四种关系都是语义级别的，所以从代码层面并不能完全区分各种关系，但总的来说，后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖。

根据前面讲的内容可以发现继承的缺点远远多于优点，尽管继承在学习OOP的过程中得到了大量的强调，但并不意味着应该尽可能地到处使用它。相反，使用它时要特别慎重。只有在清楚知道继承在所有方法中最有效的前提下，才可考虑它。 继承最大的优点就是扩展简单，但大多数缺点都很致命，但是因为这个扩展简单的优点太明显了，很多人并不深入思考，所以造成了太多问题。

1、精心设计专门用于被继承的类，继承树的抽象层应该比较稳定，一般不要多于三层。

2、对于不是专门用于被继承的类，禁止其被继承。

3、优先考虑用组合关系来提高代码的可重用性。

4、子类是一种特殊的类型，而不只是父类的一个角色

5、子类扩展，而不是覆盖或者使父类的功能失效

讨论一下组合，聚合和继承的关系与区别

聚合与组合

聚合与组合都是一种关联关系，只是额外具有整体-部分的意义。部件的生命周期不同，在聚合关系中，整件不会拥有部件的生命周期，所以整件删除时，部件不会被删除。再者，多个整件可以共享同一个部件。在组合关系中，整件拥有部件的生命周期，所以整件删除时，部件一定会跟着删除。而且，多个整件不可以同时间共享同一个部件。这个区别可以用来区分某个关联关系到底是组合还是聚合。两个类生命周期不同步，则是聚合关系，生命周期同步就是组合关系。聚合关系是【has-a】关系，组合关系是【contains-a】关系。平时我们只讨论组合和继承的时候，认为组合是【has-a 】关系，而事实上，聚合才是真正的【has-a】关系，组合是更深层次的【contains-a】关系。

由于【contains-a】关系是一种更深的【has-a】关系，所以说组合是【has-a】关系也是正确的。

组合和继承

这个才是本文的重点。学过设计模式的都知道，要“少用继承，多用组合”，这究竟是为什么呢？

我们先来看一下组合和继承各自的优缺点：

组合和继承的优缺点

组合

优点：不破坏封装、整体类于局部类之间松耦合、彼此相对独立、具有较好的可扩展性、支持动态组合，在运行时，整体对象可以选择不同类型的局部对象、整体类可以局部类进行包装，封装局部类的接口，提供新接口、支持动态组合，在运行时整体对象

缺点：

整体类不能自动获得和局部类同样的接口、创建整体类的对象时，需要创建所有局部类的对象

1、为什么继承破坏封装性？：鸭子中不想要“飞”的方法，但因为继承无法封装这个无用的“飞”方法 。

2、为什么继承紧耦合：当作为父类的BaseTable中感觉Insert这个名字不合适时，如果希望将其修改成Create方法，那使用了子类对象Insert方法将会编译出错，可能你会觉得这改起来还算容易，因为有重构工具一下子就好了并且编译错误改起来很容易。但如果BaseTable和子类在不同的程序集中，维护的人员不同，BaseTable程序集升级，那本来能用的代码忽然不能用了，这还是很难让人接受的。

3、为什么继承扩展起来比较复杂：当 图书 和数码的算税方式和数码产品一样时，而消费类产品的算税方式是另一样时，如果采用继承方案可能会演变成如下方式：这样如果产品继续增加，算税方式继续增加，那继承的层次会非常复杂，而且很难控制，而使用组合就能很好的解决这个问题。

4、继承不能支持动态继承：这个其实很好理解，因为继承是编译期就决定下来的，无法在运行时改变，如3例中，如果用户需要根据当地的情况选择计税方式，使用继承就解决不了，而使用组合结合反射就能很好的解决。

5、为什么继承，子类不能改变父类接口：因为继承的原因无法改变

组合与继承的区别和联系

在继承结构中，父类的内部细节对于子类是可见的。所以我们通常也可以说通过继承的代码复用是一种 白盒式代码复用。（如果基类的实现发生改变，那么派生类的实现也将随之改变。这样就导致了子类行为的不可预知性）

组合是通过对现有的对象进行拼装（组合）产生新的、更复杂的功能。因为在对象之间，各自的内部细节是不可见的，所以我们也说这种方式的代码复用是黑盒式代码复用 。（因为组合中一般都定义一个类型，所以在编译期根本不知道具体会调用哪个实现类的方法）

继承在写代码的时候就要指名具体继承哪个类，所以，在编译期就确定了关系。（从基类继承来的实现是无法在运行期动态改变的，因此降低了应用的灵活性。）组合，在写代码的时候可以采用面向接口 编程 。所以，类的组合关系一般在运行期确定。

组合(has-a)关系可以显式地获得被包含类（继承中称为父类）的对象，而继承(is-a)则是隐式地获得父类的对象，被包含类和父类对应，而组合外部类和子类对应。组合是在组合类和被包含类之间的一种松耦合关系，而继承则是父类和子类之间的一种紧耦合关系。当选择使用组合关系时，在组合类中包含了外部类的对象，组合类可以调用外部类必须的方法，而使用继承关系时，父类的所有方法和变量都被子类无条件继承，子类不能选择。最重要的一点，使用继承关系时，可以实现类型的回溯，即用父类变量引用子类对象，这样便可以实现多态，而组合没有这个特性。还有一点需要注意，如果你确定复用另外一个类的方法永远不需要改变时，应该使用组合，因为组合只是简单地复用被包含类的接口，而继承除了复用父类的接口外，它甚至还可以覆盖这些接口，修改父类接口的默认实现，这个特性是组合所不具有的。从逻辑上看，组合最主要地体现的是一种整体和部分的思想，例如在电脑类是由内存类，CPU类，硬盘类等等组成的，而继承则体现的是一种可以回溯的父子关系，子类也是父类的一个对象。这两者的区别主要体现在类的抽象阶段，在分析类之间的关系时就应该确定是采用组合还是采用继承。引用网友的一句很经典的话应该更能让大家分清继承和组合的区别：组合可以被说成“我请了个老头在我家里干活” ，继承则是“我父亲在家里帮我干活”。

继承还是组合？

首先它们都是实现系统功能重用，代码复用的最常用的有效的设计技巧，都是在设计模式中的基础结构。很多人都知道面向对象中有一个比较重要的原则『多用组合、少用继承』或者说『组合优于继承』。从前面的介绍已经优缺点对比中也可以看出，组合确实比继承更加灵活，也更有助于代码维护。所以，建议在同样可行的情况下，优先使用组合而不是继承。因为组合更安全，更简单，更灵活，更高效。注意，并不是说继承就一点用都没有了，前面说的是【在同样可行的情况下】。有一些场景还是需要使用继承的，或者是更适合使用继承。继承要慎用，其使用场合仅限于你确信使用该技术有效的情况。一个判断方法是，问一问自己是否需要从新类向基类进行向上转型。如果是必须的，则继承是必要的。反之则应该好好考虑是否需要继承。只有当子类真正是超类的子类型时，才适合用继承。换句话说，对于两个类A和B，只有当两者之间确实存在 is-a 关系的时候，类B才应该继承类A。