区分关联、依赖和聚合、合成的关系

摘自《Java面向对象编程》一书,作者:孙卫琴

在建立对象模型时,很容易把依赖、关联和聚集关系混淆。当对象A和对象B之间存在依赖、关联或聚集关系时,对象A都有可能调用对象B的方法,这是三种关系之间的相同之处,除此之外,它们有着不同的特征。

  • 关联(Association)关系是类与类之间的联接,它使一个类知道另一个类的属性方法。关联可以是双向的,也可以是单向的。在Java语言里,关联关系是使用实例变量实现的。
  • 聚合(Aggregation)关系是关联关系的一种,是强的关联关系。聚合是整体和个体之间的关系。例如,汽车类与引擎类、轮胎类,以及其它的零件类之间的关系便整体和个体的关系。与关联关系一种,聚合关系也是通过实例变量实现的。但是关联关系所涉及的两个类是处在同一层次上的,而在聚合关系中,两个类是处在不平等层次上的,一个代表整体,另一个代表部分。
  • 合成(Composition)关系是关联关系的一种,是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分对象的生命周期,合成关系是不能共享的。代表整体的对象需要负责保持部分对象和存活,在一些情况下将负责代表部分的对象湮灭掉。代表整体的对象可以将代表部分的对象传递给另一个对象,由后者负责此对象的生命周期。换言之,代表部分的对象在每一个时刻只能与一个对象发生合成关系,由后者排他地负责生命周期。部分和整体的生命周期一样。
  • 依赖(Dependency)也是类与类之间的连接,依赖总是单向的。依赖关系表示一个类依赖于另一个类的定义。例如,一个人(Person)可以买车(car)和房子(House),Person类依赖于Car类和House类的定义,因为Person类引用了Car和House。与关联不同的是,Person类里并没有Car和House类型的属性,Car和House的实例是以参量的方式传入到buy()方法中去的。一般而言,依赖关系在Java语言中体现为局域变量、方法的参量,以及对静态方法调用。每一个依赖关系都有一个名字。

    1.依赖关系的特征


    对于两个相对独立的系统,当一个系统负责构造另一个系统的实例,或者依赖另一个系统的服务时,这两个系统之间主要体现为依赖关系,例如生产零件的机器和零件,机器负责构造零件对象。再例如充电电池和充电器,充电电池通过充电器来充电。再例如自行车Bicycle和打气筒Pump,自行车通过打气筒来充气。图1-39为Bicycle类与Pump类的类框图。



    图1-39 Bicycle类与Pump类的依赖关系

    Bicycle类和Pump类之间是依赖关系,在Bicycle类中无需定义Pump类型的变量。Bicycle类的定义如下:

    public class Bicycle{
    /** 给轮胎充气 */
    public void expand(Pump pump){
    pump.blow();
    }
    }


    在现时生活中,通常不会为某一辆自行车配备专门的打气筒,而是在需要充气的时候,从附近某个修车棚里借个打气筒打气。在程序代码中,表现为Bicycle类的expand()方法有个Pump类型的参数。以下程序代码表示某辆自行车先后到两个修车棚里充气:

    myBicycle.expand(pumpFromrepairshed1); //到第一个修车棚里充气
    myBicycle.expand(pumpFromrepairshed2); //若干天后,到第二个修车棚里充气

    2.关联关系的特征
    对于两个相对独立的系统,当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系时,这两个系统之间为关联关系。例如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司;再例如自行车和主人,每辆自行车属于特定的主人,每个主人有特定的自行车,图1-40显示了主人和自行车的关联关系。而充电电池和充电器之间就不存在固定的对应关系,同样自行车和打气筒之间也不存在固定的对应关系。

    图1-40 主人和自行车的关联关系


    Person类与Bicycle类之间存在关联关系,这意味着在Person类中需要定义一个Bicycle类型的成员变量。以下是Person类的定义:

    public class Person{
    private Bicycle bicycle; //主人的自行车

    public Bicycle getBicycle(){
    return bicycle;
    }
    public void setBicycle(Bicycle bicycle){
    this.bicycle=bicycle;
    }
    /** 骑自行车去上班 */
    public void goToWork(){
    bicycle.run();
    }
    }


    在现时生活中,当你骑自行车去上班时,只要从家里推出自己的自行车就能上路了,不象给自行车打气那样,在需要打气时,还要四处去找修车棚。因此,在Person类的goToWork()方法中,调用自身的bicycle对象的run()方法。假如goToWork()方法采用以下的定义方式:

    /** 骑自行车去上班 */
    public void goToWork(Bicycle bicycle){
    bicycle.run();
    }

    那就好比去上班前,还要先四处去借一辆自行车,然后才能去上班。


    3.聚集关系的特征


    当系统A被加入到系统B中,成为系统B的组成部分时,系统B和系统A之间为聚集关系。例如自行车和它的响铃、龙头、轮胎、钢圈以及刹车装置就是聚集关系,因为响铃是自行车的组成部分。而人和自行车不是聚集关系,因为人不是由自行车组成的,如果一定要研究人的组成,那么他应该由头、躯干和四肢等组成。由此可见,可以根据语义来区分关联关系和聚集关系。

    聚集关系和关联关系的区别还表现在以下方面:

    (1) 对于具有关联关系的两个对象,多数情况下,两者有独立的生命周期。比如自行车和他的主人,当自行车不存在了,它的主人依然存在;反之亦然。但在个别情况下,一方会制约另一方的生命周期。比如客户和订单,当客户不存在,它的订单也就失去存在的意义。

    (2) 对于具有聚集关系(尤其是强聚集关系)的两个对象,整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周期依赖于整体类的对象的生命周期,当整体消失,部分也就随之消失。比如小王的自行车被偷了,那么自行车的所有组件也不存在了,除非小王事先碰巧把一些可拆卸的组件(比如车铃和坐垫)拆了下来。
    不过,在用程序代码来表示关联关系和聚集关系时,两者比较相似。图1-41为自行车Bicycle与响铃Bell的聚集关系。

    图1-41 自行车和响铃的聚集关系

    以下例程1-6是Bicycle类的源程序。

    例程1-6 Bicycle.java

    public class Bicycle{
    private Bell bell;

    public Bell getBell(){
    return bell;
    }

    public void setBell(Bell bell){
    this.bell=bell;
    }

    /** 发出铃声 */
    public void alert(){
    bell.ring();
    }
    }

    在Bicycle类中定义了Bell类型的成员变量,Bicycle类利用自身的bell成员变量来发出铃声,这和在Person类中定义了Bicycle类型的成员变量,Person类利用自身的bicycle成员变量去上班很相似。

  • 版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

    相关推荐


    迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图:提供一种方法顺序访问一个聚合对象中的每个元素,而又不想暴露该对象的内部表示。应用:STL标准库迭代器实现、Java集合类型迭代器等模式结构:心得:迭代器模式的目的是在不获知集合对象内部细节的同时能对集合元素进行遍历操作
    高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,常见的IO模型有四种:(1)同步阻塞IO(BlockingIO):即传统的IO模型。(2)同步非阻塞IO(Non-blockingIO):默认创建的socket都是阻塞的,非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的N
    策略模式(Strategy)策略模式(Strategy)[Policy]意图:定义一系列算法,把他们封装起来,并且使他们可以相互替换,使算法可以独立于使用它的客户而变化。应用:排序的比较方法、封装针对类的不同的算法、消除条件判断、寄存器分配算法等。模式结构:心得:对对象(Context)的处理操作可
    访问者模式(Visitor)访问者模式(Visitor)意图:表示一个作用于某对象结构中的各元素的操作,它使你在不改变各元素的类的前提下定义作用于这些元素的新操作。应用:作用于编译器语法树的语义分析算法。模式结构:心得:访问者模式是要解决对对象添加新的操作和功能时候,如何尽可能不修改对象的类的一种方
    命令模式(Command)命令模式(Command)[Action/Transaction]意图:将一个请求封装为一个对象,从而可用不同的请求对客户参数化。对请求排队或记录请求日志,以及支持可撤消的操作。应用:用户操作日志、撤销恢复操作。模式结构:心得:命令对象的抽象接口(Command)提供的两个
    生成器模式(Builder)生成器模式(Builder)意图:将一个对象的构建和它的表示分离,使得同样的构建过程可以创建不同的表示。 应用:编译器词法分析器指导生成抽象语法树、构造迷宫等。模式结构:心得:和工厂模式不同的是,Builder模式需要详细的指导产品的生产。指导者(Director)使用C
    设计模式学习心得《设计模式:可复用面向对象软件的基础》一书以更贴近读者思维的角度描述了GOF的23个设计模式。按照书中介绍的每个设计模式的内容,结合网上搜集的资料,我将对设计模式的学习心得总结出来。网络上关于设计模式的资料和文章汗牛充栋,有些文章对设计模式介绍生动形象。但是我相信“一千个读者,一千个
    工厂方法模式(Factory Method)工厂方法模式(Factory Method)[Virtual Constructor]意图:定义一个用于创建对象的接口,让子类决定实例化哪一个类,使一个类的实力化延迟到子类。应用:多文档应用管理不同类型的文档。模式结构:心得:面对同一继承体系(Produc
    单例模式(Singleton)单例模式(Singleton)意图:保证一个类只有一个实例,并提供一个访问它的全局访问点。应用:Session或者控件的唯一示例等。模式结构:心得:单例模式应该是设计模式中最简单的结构了,它的目的很简单,就是保证自身的实例只有一份。实现这种目的的方式有很多,在Java中
    装饰者模式(Decorator)装饰者模式(Decorator)[Wrapper]意图:动态的给一个对象添加一些额外的职责,就增加功能来说,比生成子类更为灵活。应用:给GUI组件添加功能等。模式结构:心得:装饰器(Decorator)和被装饰的对象(ConcreteComponent)拥有统一的接口
    抽象工厂模式(Abstract Factory)抽象工厂模式(Abstract Factory)[Kit]意图:提供一个创建一系列相关或相互依赖对象的接口,而无须指定他们具体的类。应用:用户界面工具包。模式结构:心得:工厂方法把生产产品的方式封装起来了,但是一个工厂只能生产一类对象,当一个工厂需要生
    桥接模式(Bridge)桥接模式(Bridge)[Handle/Body]意图:将抽象部分与它的实现部分分离,使他们都可以独立的变化。应用:不同系统平台的Windows界面。模式结构:心得:用户所见类体系结构(Window派生)提供了一系列用户的高层操作的接口,但是这些接口的实现是基于具体的底层实现
    适配器模式(Adapter)适配器模式(Adapter)[Wrapper]意图:将类的一个接口转换成用户希望的另一个接口,使得原本由于接口不兼容而不能一起工作的类可以一起工作。应用:将图形类接口适配到用户界面组件类中。模式结构:心得:适配器模式一般应用在具有相似接口可复用的条件下。目标接口(Targ
    组合模式(Composition)组合模式(Composition)意图:将对象组合成树形结构以表示“部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。应用:组合图形、文件目录、GUI容器等。模式结构:心得: 用户(Client)通过抽象类(Component)提供的公用接口统一
    原型模式(Prototype)原型模式(Prototype)意图:用原型实例制定创建对象的种类,并且通过拷贝这些原型创建新的对象。应用:Java/C#中的Clonable和IClonable接口等。模式结构:心得:原型模式本质上就是对象的拷贝,使用对象拷贝代替对象创建的原因有很多。比如对象的初始化构
    什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
    单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
    动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
    适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
    策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。