类和类之间的关系（第一章）

这一块我打算分几章来跟大家分享一下

一、关联关系

在一个类A的里面，声明另一个类B的成员变量（在方法外）。

类图我就不多说了，网上有很多。

双向关联（顾客和商品的关系）

单向关联（顾客和地址的关系）

自关联（节点）

多重性关联关系（界面和按钮的关系）

聚合关系（汽车和引擎的关系）

组合关系（头和嘴的关系）

（聚合和组合代码的表现形式是一样的，代码如下，区别仅仅在于语义上面）

聚合：

1、构造注入：

public class Engine{     }public class Car{     private Engine engine;     public Car(Engine engine)     {          this.engine = engine;     }}

2、set注入：

public class Engine{     }public class Car{     private Engine engine;     public void setEngine(Engine engine)     {          this.engine = engine;     }     public Engine getEngine()     {          return this.engine;     }}

3、接口注入：

public interface Engine{     public void a();}public class EngineImpl implements Engine{     public void a()     {     }}public class Car{     private Engine engine;     public void init()     {          Object obj = Class.forName("此处是接口的实现类").newInstance();          engine = (Engine) obj;          engine.a();     }}

组合也可以有这三种实现，只不过是另外的例子，例如头和嘴，电脑和CPU，等等。。。

介绍一下这三种注入方式的区别：

1、接口注入模式具有侵入性（侵入性是指一个类A实现了一个接口B或者继承了类C，那么这个类就能够访问接口B或者类C中的所有的public方法，而这些方法并不是接口B或类C想要类A访问的），所以并不被看好。

2、构造注入的优势：

     a、在构造期间就创建了一个对象

     b、避免了繁琐的set方法的编写，所有的依赖关系均在构造函数中设定，依赖关系集中呈现了出来

     c、被引用的对象，一旦通过构造方法创建之后，就处于相对稳定的状态，不用担心调用set方法重新设置了引用对象，而破坏了组件之间的依赖关系

     d、只有组件(类似上面的Car类)的创建者需要关系组件的依赖关系，对于调用者来说，组件之间的依赖关系是隐蔽的，处于黑盒之中(因为在构造方法里面)，屏蔽了不必要的信息

     e、我们可以设定依赖关系的注入顺序

3、Set注入的优势：

     a、更加直观、自然

     b、依赖关系非常复杂的情况下，全部都在构造方法里面实现就会显得相当的庞大，而此时用set注入模式更加简洁

     c、如果遇到这样的情况，我们必须提供一个默认的构造方法，那么构造注入模式就无用武之地了，只好用Set注入模式了。

第二章我再简单讲一下依赖的关系，敬请期待。。。