UML六种关系在代码中的体现你真的清楚吗?

11 篇文章 4 订阅
10 篇文章 1 订阅

文章目录

前言

一、IDEA中UML关系的表示

 二、UML六大关系在代码中的体现——IDEA图形展示

①继承关系:子类实现父类:extends

②实现关系:实现接口:implements

③组合关系:整体与局部的关系,同生共死。

④聚合关系:群体与个体的关系,非同生死。

⑤关联关系:全局变量

⑥依赖关系:方法的参数、方法内变量(局部变量)、方法的返回值类型

总结


前言

本篇文章是小编采用代码与图(IDE逆向工程生成)对应的方式进行研究和探索。

众所周知,uml六种关系强弱表示:继承>实现>组合>聚合>关联>依赖。

关于UML中六大关系的图形表示想必大家已经了然于胸,但是不同的IDE工具对于这六种关系的图形展示也有所不同,本篇文章小编首先要为大家介绍IDE开发工具——IDER的图形表示,之后再以关系从强到弱的顺序依次为大家介绍六种关系在代码中的体现。

一、IDEA中UML关系的表示

依赖:虚线普通箭头,指向被调用者,其中带有create的虚线是指创建(new)被调用者。


image

关联、聚合和组合:

实线+菱形箭头+普通箭头,菱形箭头指向整体,普通箭头指向部分,箭头两端的数字表示实例的个数。

特别注意 :IDEA中关联、聚合和组合使用同一种符号表示。


image

实现:绿色虚线三角形箭头,指向接口。


image

继承(泛化):蓝色实线三角形箭头,指向父类。


image

对于内部类:

 二、UML六大关系在代码中的体现——IDEA图形展示

①继承关系:子类实现父类:extends

public class Jeep extends Car {

}

②实现关系:实现接口:implements

public class Car implements Fly {

}

③组合关系:整体与局部的关系,同生共死。

public class Car{
    private Framework framework;
    public Car() {
        this.framework = new Framework(null);
    }
}

 

上面类Car与类Framework的关系如图所示,一条依赖关系<<create>>,一条关联关系(在idea生成的图中关联,聚合,组合关系用同一种方式表示。)

这样说来,这二者最强的关系是关联,所以,二者间至少是关联关系。其中,菱形指向的一方代表整体,而箭头指向的一方代表局部,1代表在1个Car类中有1个Framework类实例。

其中,把代码中Car构造方法去掉,就会发现类间关系变成了只有一个关联关系(上图中Car与Framework右侧的线),可得,在构造方法中创建Framework类的实例代表的是 依赖关系<<create>>这条线。

而为什么小编得出上面的代码就是组合关系呢??别急,我们和聚合关系对比来看。

④聚合关系:群体与个体的关系,非同生死。

public class Car{
    private Framework framework;
    public Car(Framework framework) {
        this.framework = framework;
    }
}

通过代码逆向工程生成的图,我们可以看到:类Car与类Framework间关系是:一条依赖关系,一条关联关系,和组合中的做法相同,我们把Car构造方法代码去掉,会发现只剩下关联关系,所以,Car构造方法中代表的是两个类间的 依赖关系。

这种写法和组合中的代码有什么不同呢?

  • 组合关系是在类Car的构造方法中实例化另一个类(Framework),所以在类Car实例化时类Framework会先被实例化,类Framework与类Car是同生共死的关系。
  • 而这个是通过类Car的构造函数传参的方式将另一个类(Framework)的实例以函数参数的形式传进来,这样Framework类的对象是在类Car外部实例化的,实例化完才作为类Car的构造函数参数传进类Car,这样即使类Car没有实例化或者不存在,都不应现类Framework进行自己的实例化,所以类Framework与类Car不是同生共死的关系,这样体现的是组合关系。

由此得出,依赖关系上带有 <<create>>标志的关系相对于不带有 <<create>>标志的耦合更强一些,也就是关系更强。由此,得出结论:在Idea逆向工程生成的图中,依赖关系 <<create>>标志+关联,可以理解为组合关系,而普通依赖关系+关联,可以理解为聚合关系。当然,组合和聚合关系的前提是关联关系。(代码体现也就是Car类内部,方法外部声明的 Framework 类变量)

⑤关联关系:全局变量

public class Car{
    private Framework framework;
}

说明:了解了组合和聚合关系后,我们对关联关系自然也明白了,因为关联关系是聚合和组合的基础。在类A内部,方法外部声明的类B的变量,这两类间的关系就可以说成是关联关系。因为类B变量的生命周期与类A是相同的,比依赖关系要强,所以,是关系关系。

注意:确定了关联关系后再寻找更强的关系(聚合还是组合),还需要进一步观察代码。

依赖关系:方法的参数、方法内变量(局部变量)、方法的返回值类型

// 类Car与类Framework的依赖关系:

public class Car{
    //case 1:参数
    public Car(Framework framework) {
    ......
    }
    
    //case 2:返回值
    public Framework run() {
        return null;
    }
    
    //case 3:方法内变量

    public void run() {
        Framework framework;
    }
}

这三种情况下类间关系是依赖,因为Framework类在Car类的生命周期中占了局部,对于类来说,方法是局部的,类本身是全局的,所以局部的关系一定比全局弱,所以在方法内部声明的类变量,类间关系是依赖。简单一句话总结:区分依赖与关联关系就要看一个类在另一个类中生命周期的长短。

总结

以上对于UML的六种关系,都是经过小编根据代码与图对应实践后得出的结论,如有不同观点,欢迎交流。

 

参考博客:

https://blog.csdn.net/weixin_42653522/article/details/113858021

https://blog.csdn.net/whc888666/article/details/109975393

 

  • 3
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 20
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 20
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Ariel_欢

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值