下面是小编为大家整理的类与类之间关系（2022年）,供大家参考。
类与类之间的关系对于理解面向对象具有很重要的作用， 下面进行总结！
一、 类与类之间存在以下关系: `
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()
1 0.
{
1 1 .
Animal a=new Tiger();
1 2.
}
1 3. }
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.
{
1 0.
this.employee=employee;
1 1 .
}
1 2.
//公司运作
1 3.
public void run()
1 4.
{
1 5.
employee.startWorking();
1 6.
}
1 7. }
1 8.
(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.
//开启电脑
1 0.
public void start(){
1 1 .
//cpu 运作
1 2.
cpu.run();
1 3.
}
1 4. }
那依赖和聚合\组合、 关联等有什么不同呢？
关联是类之间的一种关系， 例如老师教学生， 老公和老婆， 水壶装水等就是一种关系。
这种关系是非常明显的， 在问题领域中通过分析直接就能得出。
依赖是一种弱关联， 只要一个类用到另一个类， 但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类）
， 就可以把这种关系看成是依赖， 依赖也 可说是一种偶然的关系， 而不是必然的关系， 就是“我在某个方法中偶然用到了 它， 但在现实中我和它并没多大关系”。
例如我和锤子， 我和锤子本来是没关系的，
但在有一次要钉钉子的时候， 我用到了 它， 这就是一种依赖， 依赖锤子完成钉钉子这件事情。
组合是一种整体-部分的关系， 在问题域中这种关系很明显， 直接分析就可以得出的。
例如轮胎是车的一部分， 树叶是树的一部分， 手脚是身体的一部分这种的关系， 非常明显的整体-部分关系。
上述的几种关系（关联、 聚合/组合、 依赖）
在代码中可能以指针、 引用、 值等的方式在另一个类中出现， 不拘于形式， 但在逻辑上他们就有以上的区别。
这 里还要说明一下， 所谓的这些关系只是在某个问题域才有效， 离开了 这个问题域， 可能这些关系就不成立了， 例如可能在某个问题域中， 我是一个木匠， 需要拿着锤 子去干活， 可能整个问题的描述就是我拿着锤子怎么钉桌子， 钉椅子， 钉柜子； 既然整个问题就是描述这个， 我和锤子就不仅是偶然的依赖关系了， 我和锤子的关系 变得非常的紧密， 可能就上升为组合关系（让我突然想起武侠小说的剑不离身， 剑亡人亡...）
。
这个例子可能有点荒谬， 但也是为了说明一个道理， 就是关系和 类一样， 它们都是在一个问题领域中才成立的， 离开了这个问题域， 他们可能就不复存在了 。
组合和聚合的区别：
当类之间有整体-部分关系的时候， 我们就可以使用组合或者聚合。
聚合：
表示 C9 聚合 C10， 但是 C10 可以离开 C9 而独立存在（独立存在的意思是在某个应用的问题域中这个类的存在有意义。
这句话怎么解， 请看下面组合里的解释）
。
组 合（也有人称为包容）
：
一般是实心菱形加实线箭头表示， 如上图所示， 表示的是 C8被 C7 包容， 而且 C8 不能离开 C7 而独立存在。
但这是视问题域而定的， 例 如在关心汽车的领域里， 轮胎是一定要组合在汽车类中的， 因为它离开了汽车就没有意义了。
但是在卖轮胎的店铺业务里， 就算轮胎离开了汽车， 它也是有意义的，
这就可以用聚合了。
在《敏捷开发》 中还说到， A 组合 B， 则 A 需要知道 B 的生存周期， 即可能 A 负责生成或者释放 B，或者 A 通过某种途径知道 B 的生成和释放。