类与类之间的关系

类与类之间的关系对于理解面向对象具有很重要的作用,下面进行总结!

一、类与类之间存在以下关系:
`     

UML图与应用代码例子:
1.泛化(Generalization)
[泛化]
表示类与类之间的继承关系,接口与接口之间的继承关系,或类对接口的实现关系。一般化的关系是从子类指向父类的,与继承或实现的方法相反。

 [简单理解]

是一个 is a  的关系。如老虎是一个动物

[具体表现]
父类 父类实例=new 子类
()
[UML](
1.1)

1.1 Animal类与Tiger,Dog类的泛化关系

[代码表现]

1.       class Animal{

2.        

3.       }   

4.       class Tiger extends Animal {

5.        

6.       }   

7.       public class Test   

8.       {   

9.           public void test()   

10.       {   

11.           Animal a=new Tiger();   

12.       }   

13.   }  


2.依赖(Dependency)
[依赖]
对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系。

[具体表现]
依赖关系表现在局部变量方法的参数,以及对静态方法的调用

[简单理解 ]
一个类使用了另外一个类作为局部变量和方法参数。是一个 use a关系!

[
现实例子]
比如说你要去拧螺丝,你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作

[UML表现](1.2)
有时在uml图中不出现箭头只是虚线


1.2 Person类与Screwdriver类的依赖关系
理解:
Person类可能要用到Screwdriver的一些方法,也可以这样说,要完成Person里的所有功能,一定要有Screwdriver的方法协助才行。Person依赖于Screwdriver的定义。

ROSE对依赖关系不产生属性。
注意,要避免双向依赖。一般来说,不应该存在双向依赖
[代码表现]

1.       public class Person

2.       {   

3.           /** 拧螺丝 */  

4.           public void screw(Screwdriver screwdriver)

5.         {   

6.               screwdriver.screw();   

7.           }   

8.       }  

 

 

 


3.关联(Association)
[关联]
对于两个相对独立的对象,当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时,这两个对象之间为关联关系。

[具体表现]
关联关系是使用实例变量来实现

[现实例子]
比如客户和订单,每个订单对应特定的客户,每个客户对应一些特定的订单;

再例如公司和员工,每个公司对应一些特定的员工,每个员工对应一特定的公司
[UML] (1.3)

1.3 公司和员工的关联关系


[代码表现]

1.    public class Company

2.       {   

3.           private Employee employee;   

4.           public Employee getEmployee()

5.         {   

6.               return employee;   

7.           }   

8.           public void setEmployee(Employee employee)

9.         {   

10.           this.employee=employee;   

11.       }   

12.       //公司运作   

13.       public void run()

14.     {   

15.           employee.startWorking();   

16.       }   

17.   }

18.    

 

 

(4)聚合(Aggregation
[聚合]
当对象A被加入到对象B中,成为对象B的组成部分时,对象B和对象A之间为聚集关系。聚合是关联关系的一种,是较强的关联关系,强调的是整体部分之间的关系。

[具体表现]
与关联关系一样,聚合关系也是通过实例变量来实现这样关系的。关联关系和聚合关系来语法上是没办法区分的,从语义上才能更好的区分两者的区别。

[关联与聚合的区别]
(1)关联关系所涉及的两个对象是处在同一个层次上的。比如人和自行车就是一种关联关系,而不是聚合关系,因为人不是由自行车组成的。
聚合关系涉及的两个对象处于不平等的层次上,一个代表整体,一个代表部分。比如电脑和它的显示器、键盘、主板以及内存就是聚集关系,因为主板是电脑的组成部分。
(2)对于具有聚集关系(尤其是强聚集关系)的两个对象,整体对象会制约它的组成对象的生命周期。部分类的对象不能单独存在,它的生命周期依赖于整体类的 对象的生命周期,当整体消失,部分也就随之消失。比如张三的电脑被偷了,那么电脑的所有组件也不存在了,除非张三事先把一些电脑的组件(比如硬盘和内存) 拆了下来。
[UML](1.4)

1.3 电脑和组件的聚合关系
[代码表现]

1.    public class Computer{   

2.           private CPU cpu;   

3.           public CPU getCPU(){   

4.               return cpu;   

5.           }   

6.           public void setCPU(CPU cpu){   

7.               this.cpu=cpu;   

8.           }   

9.           //开启电脑   

10.       public void start(){   

11.           //cpu运作   

12.           cpu.run();   

13.       }   

14.   }  

那依赖和聚合\组合、关联等有什么不同呢?

关联是类之间的一种关系,例如老师教学生,老公和老婆,水壶装水等就是一种关系。这种关系是非常明显的,在问题领域中通过分析直接就能得出。

依赖是一种弱关联,只要一个类用到另一个类,但是和另一个类的关系不是太明显的时候(可以说是“uses”了那个类),就可以把这种关系看成是依赖,依赖也 可说是一种偶然的关系,而不是必然的关系,就是我在某个方法中偶然用到了它,但在现实中我和它并没多大关系。例如我和锤子,我和锤子本来是没关系的, 但在有一次要钉钉子的时候,我用到了它,这就是一种依赖,依赖锤子完成钉钉子这件事情。

组合是一种整体-部分的关系,在问题域中这种关系很明显,直接分析就可以得出的。例如轮胎是车的一部分,树叶是树的一部分,手脚是身体的一部分这种的关系,非常明显的整体-部分关系。

上述的几种关系(关联、聚合/组合、依赖)在代码中可能以指针、引用、值等的方式在另一个类中出现,不拘于形式,但在逻辑上他们就有以上的区别。

里还要说明一下,所谓的这些关系只是在某个问题域才有效,离开了这个问题域,可能这些关系就不成立了,例如可能在某个问题域中,我是一个木匠,需要拿着锤 子去干活,可能整个问题的描述就是我拿着锤子怎么钉桌子,钉椅子,钉柜子;既然整个问题就是描述这个,我和锤子就不仅是偶然的依赖关系了,我和锤子的关系 变得非常的紧密,可能就上升为组合关系(让我突然想起武侠小说的剑不离身,剑亡人亡...)。这个例子可能有点荒谬,但也是为了说明一个道理,就是关系和 类一样,它们都是在一个问题领域中才成立的,离开了这个问题域,他们可能就不复存在了。

组合和聚合的区别:
当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合。


聚合:表示C9聚合C10,但是C10可以离开C9而独立存在(独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解,请看下面组合里的解释)。


合(也有人称为包容):一般是实心菱形加实线箭头表示,如上图所示,表示的是C8C7包容,而且C8不能离开C7而独立存在。但这是视问题域而定的,例 如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的, 这就可以用聚合了。在《敏捷开发》中还说到,A组合B,则A需要知道B的生存周期,即可能A负责生成或者释放B,或者A通过某种途径知道B的生成和释放。

(1)抽象:从许多事物中舍弃个别的、非本质的特征,抽取共同的、本质性的特征,就叫作抽象。抽象是形成概念的必须手段。 抽象原则有两方面的意义:第一,尽管问题域中的事物是很复杂的,但是分析员并不需要了解和描述它们的一切,只需要分析研究其中与系统目标有关的事物及其本质性特征。第二,通过舍弃个体事物在细节上的差异,抽取其共同特征而得到一批事物的抽象概念。 抽象是面向对象方法中使用最为广泛的原则。抽象原则包括过程抽象和数据抽象两个方面。 过程抽象是指,任何一个完成确定功能的操作序列,其使用者都可以把它看作一个单一的实体,尽管实际上它可能是由一系列更低级的操作完成的。 数据抽象是根据施加于数据之上的操作来定义数据型,并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据(属性)和操作(服务)结合为一个不可分的系统单位(即对象),对象的外部只需要知道它做什么,而不必知道它如何做。 (2)封装就是把对象的属性和服务结合为一个不可分的系统单位,并尽可能隐蔽对象的内部细节。 (3)继承:特殊的对象拥有的其一般的全部属性与服务,称作特殊对一般的继承。 在OOA中运用继承原则,就是在每个由一般和特殊形成的一般-特殊结构中,把一般的对象实例和所有特殊的对象实例都共同具有的属性和服务, 一次性地在一般中进行显式的定义。 在特殊中不再重复地定义一般中已定义的东西,但是在语义上,特殊却自动地、隐含地拥有它的一般 (以及所有更上层的一般)中定义的全部属性和服务。继承原则的好处是:使系统模型比较简练也比较清晰。 (4)分:就是把具有相同属性和服务的对象划分为一,用作为这些对象的抽象描述。分原则实际上是抽象原则运用于对象描述时的一种表现形式。 (5)聚合:又称组装,其原则是:把一个复杂的事物看成若干比较简单的事物的组装体,从而简化对复杂事物的描述。 (6)关联:是人思考问题时经常运用的思想方法:通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。 (7)消息通信:这一原则要求对象之间只能通过消息进行通信,而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。 (8)粒度控制:一般来讲,人在面对一个复杂的问题域时,不可能在同一时刻既能纵观全局,又能洞察秋毫。因此需要控制自己的视野:考虑全局时,注意其大的组成部分,暂时不详察每一部分的具体的细节;考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。 (9)行为分析:现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值