4.2什么是合成?什么是聚合?
合成(Composition)和聚合(Aggregation)都是关联(Association)的特殊种类。
聚合表示整体和部分的关系,表示“拥有”。如奔驰S360汽车,对奔驰S360引擎、奔驰S360轮胎的关系是聚合关系,离开了奔驰S360汽车,引擎、轮胎就失去了存在的意义。在设计中, 聚合不应该频繁出现,这样会增大设计的耦合度。[Page]
合成则是一种更强的“拥有”,部分和整体的生命周期一样。合成的新的对象完全支配其组成部分,包括它们的创建和湮灭等。一个合成关系的成分对象是不能与另一个合成关系共享的。
换句话说,合成是值的聚合(Aggregation by Value),而一般说的聚合是引用的聚合(Aggregation by Reference)。
明白了合成和聚合关系,再来理解合成/聚合原则应该就清楚了,要避免在系统设计中出现,一个类的继承层次超过3层,则需考虑重构代码,或者重新设计结构。当然最好的办法就是考虑使用合成/聚合原则。
4.3通过合成/聚合的优缺点
优点:
1) 新对象存取成分对象的唯一方法是通过成分对象的接口。
2) 这种复用是黑箱复用,因为成分对象的内部细节是新对象所看不见的。
3) 这种复用支持包装。
4) 这种复用所需的依赖较少。
5) 每一个新的类可以将焦点集中在一个任务上。
6) 这种复用可以在运行时间内动态进行,新对象可以动态的引用与成分对象类型相同的对象。
7) 作为复用手段可以应用到几乎任何环境中去。
缺点:就是系统中会有较多的对象需要管理。
4.4通过继承来进行复用的优缺点
优点:
新的实现较为容易,因为超类的大部分功能可以通过继承的关系自动进入子类。
修改和扩展继承而来的实现较为容易。
缺点:
继承复用破坏包装,因为继承将超类的实现细节暴露给子类。由于超类的内部细节常常是对于子类透明的,所以这种复用是透明的复用,又称“白箱”复用。
如果超类发生改变,那么子类的实现也不得不发生改变。
从超类继承而来的实现是静态的,不可能在运行时间内发生改变,没有足够的灵活性。
继承只能在有限的环境中使用。
五、 迪米特法则(Law of Demeter,LoD)
5.1概述
定义:一个软件实体应当尽可能少的与其他实体发生相互作用。
这样,当一个模块修改时,就会尽量少的影响其他的模块。扩展会相对容易。
这是对软件实体之间通信的限制。它要求限制软件实体之间通信的宽度和深度。
5.2迪米特法则的其他表述:
1)只与你直接的朋友们通信。
2)不要跟“陌生人”说话。
3)每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。
5.3狭义的迪米特法则
如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
朋友圈的确定
“朋友”条件:
1)当前对象本身(this)
2)以参量形式传入到当前对象方法中的对象
3)当前对象的实例变量直接引用的对象
4)当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友
5)当前对象所创建的对象
任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”;否则就是“陌生人”。
缺点:会在系统里造出大量的小方法,散落在系统的各个角落。
与依赖倒转原则互补使用
5.4狭义的迪米特法则的缺点:
在系统里造出大量的小方法,这些方法仅仅是传递间接的调用,与系统的商务逻辑无关。[Page]
遵循类之间的迪米特法则会是一个系统的局部设计简化,因为每一个局部都不会和远距离的对象有直接的关联。但是,这也会造成系统的不同模块之间的通信效率降低,也会使系统的不同模块之间不容易协调。
5.5迪米特法则与设计模式
门面(外观)模式和调停者(中介者)模式实际上就是迪米特法则的具体应用。
5.6广义的迪米特法则
迪米特法则的主要用意是控制信息的过载。在将迪米特法则运用到系统设计中时,要注意下面的几点:
1)在类的划分上,应当创建有弱耦合的类。
2)在类的结构设计上,每一个类都应当尽量降低成员的访问权限。
3)在类的设计上,只要有可能,一个类应当设计成不变类。
4)在对其他类的引用上,一个对象对其对象的引用应当降到最低。
5.7广义迪米特法则在类的设计上的体现
1)优先考虑将一个类设置成不变类
2)尽量降低一个类的访问权限
3)谨慎使用Serializable
4)尽量降低成员的访问权限
5)取代C Struct
迪米特法则又叫作最少知识原则(Least Knowledge Principle或简写为LKP),就是说一个对象应当对其他对象有尽可能少的了解。
5.8如何实现迪米特法则
迪米特法则的主要用意是控制信息的过载,在将其运用到系统设计中应注意以下几点:
1) 在类的划分上,应当创建有弱耦合的类。类之间的耦合越弱,就越有利于复用。
2) 在类的结构设计上,每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性,而应当提供取值和赋值的方法让外界间接访问自己的属性。
3) 在类的设计上,只要有可能,一个类应当设计成不变类。
4) 在对其它对象的引用上,一个类对其它对象的引用应该降到最低。
六、 接口隔离原则(interface separate principle, ISP)
6.1概念
接口隔离原则:使用多个专门的接口比使用单一的总接口要好。也就是说,一个类对另外一个类的依赖性应当是建立在最小的接口上。
这里的/"接口/"往往有两种不同的含义:一种是指一个类型所具有的方法特征的集合,仅仅是一种逻辑上的抽象;另外一种是指某种语言具体的/"接口/" 定义,有严格的定义和结构。比如c# 语言里面的Interface结构。对于这两种不同的含义,ISP的表达方式以及含义都有所不同。(上面说的一个类型,可以理解成一个类,我们定义了一个 类,也就是定义了一种新的类型)
当我们把/"接口/"理解成一个类所提供的所有方法的特征集合的时候,这就是一种逻辑上的概念。接口的划 分就直接带来类型的划分。这里,我们可以把接口理解成角色,一个接口就只是代表一个角色,每个角色都有它特定的一个接口,这里的这个原则可以叫做/"角色 隔离原则/"。 如果把/"接口/"理解成狭义的特定语言的接口,那么ISP表达的意思是说,对不同的客户端,同一个角色提供宽窄不同的接口,也就是定制服务,个性化服务。就是仅仅提供客户端需要的行为,客户端不需要的行为则隐藏起来。
应当为客户端提供尽可能小的单独的接口,而不要提供大的总接口。
这也是对软件实体之间通信的限制。但它限制的只是通信的宽度,就是说通信要尽可能的窄。[Page]
遵循迪米特法则和接口隔离原则,会使一个软件系统功能扩展时,修改的压力不会传到别的对象那里。
6.2如何实现接口隔离原则
不应该强迫用户依赖于他们不用的方法。
1、利用委托分离接口。
2、利用多继承分离接口。