大家好,欢迎来到IT知识分享网。
对于很多刚刚接触UML的童鞋,可能会对类之间的关联与依赖关系不太理解,今天小菜就浅薄的讲一下。
依赖
表现为函数中的参数(use a),是类与类之间的连接,表示一个类依赖于另一个类的定义,其中一个类的变化将影响另外一个类。例如如果A依赖于B,则B体现为局部变量,方法的参数、或静态方法的调用。如电视(TV)依赖于频道(channel)常见的依赖关系如下:
(1)类B以参数的形式传入类A的方法。我个人将它就取名为“参数依赖”。
(2)类B以局部变量的形式存在于类A的方法中。我个人将它就取名为“局部依赖”。
(3)类A调用类B的静态属性或方法。我个人将它就取名为“静态依赖”。
UML图中实现使用一条带有箭头的虚线指向被依赖的类,如下:
关联(委派)
表现为变量(has a),类与类之间的联接,它使一个类知道另一个类的属性和方法。例如如果A关联于B,则B体现为A的全局变量,如person类和company类。
关联关系有双向关联和单向关联:
1、双向关联:两个类相互都知道另一个类的公共属性和操作。
2、单向关联:只有一个类知道另外一个类的公共属性和操作。
大多数关联应该是单向的,单向关系更容易建立和维护,有助于寻找可服用的类。
UML图中实现使用一条实线(有的地方用带箭头的实线)连接相同或不同类,如下:
这块的确是有点乱,不过小菜突然找到了一个比较好的切入点,拿出来分享一下。
接触过设计模式的读者,会经常看到这样的场景:在实例化A类的时候,需要B类作为构造方法的参数,这说明A类需要持有一个B类的引用。比如代理模式、装饰 模式等,都会这样做。例如Java中的IO流采用的就是装饰模式,所以我们会经常看到这样的语句:new BufferInputStream(new FileInputStream(“c:\\1.db”));
person与company之间的关联关系也叫委派关系(我自己称呼的)。
这种持有引用,就是简单的关联关系。在代码中表现为:在A类中有一个成员变量,变量的类型是B类,A类中持有了B类的引用,就说明A类和B类发生了关联关系。
用UML图表示如下:
稍加说明,由于是A类持有B类的引用,因此关联是从A类中发出的(由A类引起),因此箭头要从A类指向B类。
通常情况下,这种简单的单向关联就够用了,但是关联关系主要还是应用在数据库设计中。
在数据库设计中,无论是一对一、一对多、多对多,都不是单向的。
从表的角度分析,它们均可以从任意一端确定另一端。就拿一对多来说,有了one端的主键,可以根据many端表的外键查出many端数据;有了many端外键,可以根据one端表的主键查出one端数据。
从实体类的角度分析,同样可以从任意一端确定另一端。还是拿一对多来说,one端的实体类会持有一个many端的引用集合,例如private Set<B> bs;,查询到了one端,可以直接从这个集合中读取many端;many端的实体类会持有一个one端的引用,例如private A a;,查询到了many端,可以直接从这个引用确定每一个many端的one端。
这样一来,就成了双向关联,用UML画关联关系的时候,两边都要加箭头,这样太难看,索性就都不加了。
例如部门实体类和员工实体类的关系,就可以这样表示:
由于是数据库实体类间的关联关系,因此还要加上数量关系,1代表one端,0..n代表many端,说明一个部门可以有多个员工,但一个员工只能属于一个部门,通过UML图描述了一对多。
这个才是关联关系典型的应用。
不得不提的是,关联关系还可以细分为聚合和组合(二者的具体概念读者自行搜索)。
小菜发现聚合、组合可以从另一个角度去理解。
先说说聚合,它是一种弱关联,大概意思就是整体和部分可以独立存在。如果我们换个角度,可以看成是数据库的级联操作。
就拿小组和组员来说,删除某个小组的时候,把该组的组员也删除,这显然是不科学的,因为小组和组员是一种弱关联,小组可以拥有任意一个组员,一个组员也可以去任意一个小组,这个小组不存在了,可以去另一个小组,它们没有必然的关联,可以称为聚合。
因此,我们在设计数据库的时候,往往不会设置级联删除,也就是说,删除小组时不会删除组员。
UML图表示如下:
空心菱形表示聚合,指向one端。
再说说组合,组合是一种强关联,大概意思是整体和部分不可分割,不能独立存在。同样从级联操作理解。
就拿学生和学生证来说,假如某个学生退学,不再属于这个学校,那么可以考虑将该学生信息删除,删除的时候,学生对应的学生证信息也会被删除,在此处可以加 级联删除。因为学生证属于某个学生专有的信息,学生不存在了,学生证又不能让他人使用,因此是一种强关联,可以称为组合。
UML图表示如下:
最后要谈的是依赖关系。
假如A类的某个方法中,使用了B类,那么就说A类依赖于B类,它们是依赖关系。
A类的某个方法使用B类,可能是方法的参数是B类,也可能是在方法中获得了一个B类实例。但无论是哪种情况,B类在A类中都是以局部变量的形式存在的。
因此,A类中有B类型的局部变量,就说A类依赖于B类。
UML图表示如下:
虚线箭头表示依赖,箭头指向被依赖的类。
综上,有一个简单的判断原则:某个类以成员变量的形式出现在另一个类中,二者是关联关系;某个类以局部变量的形式出现在另一个类中,二者是依赖关系。
注意:本文为了方便讲解,一直是拿类当例子,这并不是一种好的设计思维。实际开发中,为了更好的实现”开-闭原则”,一般都是定义接口,依赖于接口,依赖于抽象,而不是根据具体编程,希望读者不要被小菜误导!!
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://yundeesoft.com/34239.html