1.Q对象)l合是一U通过创徏一个组合了其它对象的对象,从而获得新功能的复用方法?br>
2.功能委托给所l合的一个对象,从而获得新功能?br>
3.有些时候也UC?聚合"QaggregationQ或"包容"QcontainmentQ,管有些作者对q些术语赋予了专门的含义
4.例如Q?br>
a.聚合Q一个对象拥有另一个对象或对另一个对象负责(即一个对象包含另一个对象或是另一个对象的一部分Q,q且聚合对象和其所有者具有相同的生命周期。(译者注Q即所谓的"同生共死"关系Q可参见GOF的Design
Patterns: Elements of Reusable Object-Oriented Software的引a部分。)
b.包容Q一U特D类型的l合Q对于其它对象而言Q容器中的被包含对象是不可见的,其它对象仅能通过容器对象来访问被包含对象。(CoadQ?/p>
5.包含可以通过以下两种方式实现Q?br>
a.Ҏ引用QBy referenceQ?br>
b.Ҏ|By valueQ?br>
6.CQ+允许Ҏ值或引用来实现包含?br>
7.但是在Java中,一切皆为对象的引用Q?br>
1.优点Q?/strong>
a.容器cM能通过被包含对象的接口来对其进行访问?br>
b."黑盒"复用Q因包含对象的内部细节对外是不可见?br>
c.对装性好?br>
d.实现上的怺依赖性比较小。(译者注Q被包含对象与容器对象之间的依赖关系比较)
e.每一个类只专注于一Q务?br>
f.通过获取指向其它的具有相同类型的对象引用Q可以在q行期间动态地定义Q对象的Q组合?/p>
2.~点Q?/strong>
a.从而导致系l中的对象过多?br>
bZ能将多个不同的对象作为组合块Qcomposition blockQ来使用Q必Ml地Ҏ口进行定义?br>
1.Q类Q承是一U通过扩展一个已有对象的实现Q从而获得新功能的复用方法?br>
2.泛化c(类Q可以显式地捕获那些公共的属性和Ҏ?br>
3.Ҏc(子类Q则通过附加属性和Ҏ来进行实现的扩展?br>
1.优点Q?/strong>
a.Ҏq行新的实现Q因为其大多数可l承而来?br>
b.易于修改或扩展那些被复用的实现?br>
2.~点Q?/strong>
a.破坏了封装性,因ؓq会父cȝ实现l节暴露l子cR?br>
b. "白盒"复用Q因为父cȝ内部l节对于子类而言通常是可见的?br>
c.当父cȝ实现更改Ӟ子类也不得不会随之更攏V?br>
d.从父cȝ承来的实现将不能在运行期间进行改变?br>
仅当下列的所有标准被满Ӟ方可使用l承Q?br>
a.子类表达?是一?#8230;的特D类?Q而非"是一个由…所扮演的角??br>
b子类的一个实例永q不需要{化(transmuteQؓ其它cȝ一个对象?br>
c.子类是对其父cȝ职责QresponsibilityQ进行扩展,而非重写或废除(nullifyQ?br>
d.子类没有寚w些仅作ؓ一个工LQutility classQ的功能q行扩展?br>
e.对于一个位于实际的问题域(Problem DomainQ的c而言Q其子类Ҏ一U角ԌroleQ,交易QtransactionQ或讑֤QdeviceQ?br>
1."是一?#8230;的特D类?Q而非"是一个由…所扮演的角?
-->p|。乘客是人所扮演的一U角艌Ӏ代理h亦然?br>
2.永远不需要{?br>
-->p|。随着旉的发展,一个Person的子cd例可能会从Passenger转变成AgentQ再到Agent Passenger?br>
3.扩展Q而非重写和废?br>
-->通过?br>
4.不要扩展一个工L
-->通过?br>
5.在问题域内,Ҏ一U角Ԍ交易或设?br>
-->p|。Person不是一U角Ԍ交易或设备?/p>
l承q适用于此处!
使用l合q行挽救Q?br>
1."是一?#8230;的特D类?Q而非"是一个由…所扮演的角?
-->通过。乘客和代理人都是特D类型的人所扮演的角艌Ӏ?br>
2.永远不需要{?br>
-->通过。一个Passenger对象保持不变;Agent对象亦然?br>
3.扩展Q而非重写和废?br>
-->通过?br>
4.不要扩展一个工L
-->通过?br>
5.在问题域内,Ҏ一U角Ԍ交易或设?br>
-->通过。PersonRole是一U类型的角色?br>
l承适用于此处!
1."是一?#8230;的特D类?Q而非"是一个由…所扮演的角?
-->通过。预订和购买都是一U特D类型的交易?br>
2.永远不需要{?br>
-->通过。一个Reservation对象保持不变;Purchase对象亦然?br>
3.扩展Q而非重写和废?br>
-->通过?br>
4.不要扩展一个工L
-->通过?br>
5.在问题域内,Ҏ一U角Ԍ交易或设?br>
-->通过。是一U交易?br>
l承适用于此处!
1."是一?#8230;的特D类?Q而非"是一个由…所扮演的角?
-->p|。预订不是一U特D类型的observable?br>
2.永远不需要{?br>
-->通过。一个Reservation对象保持不变?br>
3.扩展Q而非重写和废?br>
-->通过?br>
4.不要扩展一个工L
-->p|。Observable是一个工L?br>
5.在问题域内,Ҏ一U角Ԍ交易或设?br>
-->不适用。Observable是一个工LQƈ非一个问题域的类。?br>
l承q适用于此处!
1.l合与扉K是重要的重用Ҏ
2.在OO开发的早期Q承被q度C?br>
3.随着旉的发展,我们发现优先使用l合可以获得重用性与单性更佳的设计
4.当然可以通过l承Q以扩充QenlargeQ可用的l合c集Qthe set of composable classesQ?br>
5.因此l合与承可以一起工?br>
6.但是我们的基本法则是Q?br>
优先使用对象l合Q而非Q类Q?br>
[ Favor Composition Over Inheritance ]法则2Q针Ҏ口编E,而非Q接口的Q实?br>
[ Program To An Interface, Not An Implementation ]
接口
1.接口是一个对象在对其它的对象q行调用时所知道的方法集合?br>
2.一个对象可以有多个接口Q实际上Q接口是对象所有方法的一个子集)
3.cd是对象的一个特定的接口?br>
4.不同的对象可以具有相同的cdQ而且一个对象可以具有多个不同的cd?br>
5.一个对象仅能通过其接口才会被其它对象所了解?br>
6.某种意义上,接口是以一U非常局限的方式Q将"是一U?#8230;"表达?一U支持该接口?#8230;"?br>
7.接口是实现插件化QpluggabilityQ的关键
实现l承和接口?br>
1.实现l承Q类l承Q:一个对象的实现是根据另一个对象的实现来定义的?br>
2.接口l承Q子cd化)Q描qC一个对象可在什么时候被用来替代另一个对象?br>
3.C++的承机制既指类l承Q又指接口ѝ?br>
4.C++通过l承U虚cL实现接口l承?br>
5.JavaҎ口承具有单独的语言构造方式-Java接口?br>
6.Java接口构造方式更加易于表辑֒实现那些专注于对象接口的设计?br>
接口的好?br>
1.优点Q?br>
a.Client不必知道其用对象的具体所属类?br>
b.一个对象可以很Ҏ地被Q实C相同接口的)的另一个对象所替换?br>
c.对象间的q接不必绑定(hardwireQ到一个具体类的对象上Q因此增加了灉|性?br>
e.松散藕合Qloosens couplingQ?br>
f.增加了重用的可能性?br>
e.提高了(对象Q组合的机率Q因包含对象可以是Q何实C一个指定接口的cR?br>
2.~点Q?/strong>
a.设计的复杂性略有增?br>
Q译者注Q接口表C?…?#8230;"QLikeAQ的关系Q承表C?…?#8230;"QIsAQ的关系Q组合表C?…?#8230;"QHasAQ的关系。)
接口实例
该方法是指其它的一些类可以q行交通工LNQ而不必关心其实际上是Q汽车,轮船Q潜艇或是其它Q何实CIManeuverabre的对象)?
法则3Q开放-闭法则QOCPQ?br>
软gl成实体应该是可扩展的,但是不可修改的?br>
[ Software Entities Should Be Open For Extension, Yet Closed For Modification
]
开放-闭法则
1.开?闭法则认ؓ我们应该试图去设计出永远也不需要改变的模块?br>
2我们可以dC码来扩展pȝ的行为。我们不能对已有的代码进行修攏V?br>
3.W合OCP的模块需满两个标准Q?br>
4.可扩展,?Ҏ展是开攄"QOpen For ExtensionQ-模块的行为可以被扩展Q以需要满x的需求?br>
5.不可更改Q即"ҎҎ闭?QClosed for ModificationQ-模块的源代码是不允许q行改动的?br>
6.我们能如何去做呢Q?br>
a.抽象QAbstractionQ?br>
b.多态(PolymorphismQ?br>
c.l承QInheritanceQ?br>
d.接口QInterfaceQ?/p>
7. 一个Y件系l的所有模块不可能都满OCPQ但是我们应该努力最化q些不满OCP的模块数量?br>
8.开放-闭法则是OO设计的真正核心?br>
9.W合该法则便意味着最高等U的复用性(reusabilityQ和可维护性(maintainabilityQ?br>
OCPCZ
1. 考虑下面某类的方法:
![]()
2.以上函数的工作是在制订的部g数组中计各个部件h格的d?br>
3.若Part是一个基cL接口且用了多态,则该cd很容易地来适应新类型的部gQ而不必对其进行修攏V?br>
4.其将W合OCP
5. 但是在计Mh格时Q若财务部颁布主板和内存应用额外费用,则将如何d?br>
6.下列的代码是如何来做的呢Q?/p>
![]()
7.q符合OCP吗?
8.当每ơ胦务部提出新的计h{略Q我们都不得不要修改totalPrice()ҎQ这q"ҎҎ闭?。显Ӟ{略的变更便意味着我们不得不要在一些地方修改代码的Q因此我们该如何d呢?
9.Z使用我们W一个版本的totalPrice()Q我们可以将计h{略合ƈ到Part的getPrice()Ҏ中?/p>
10.q里是Part和ConcretePartcȝCZQ?br>
![]()
11. 但是现在每当计h{略发生改变Q我们就必须修改Part的每个子c!
12.一个更好的思\是采用一个PricePolicyc,通过对其q行l承以提供不同的计h{略Q?br>
13.看v来我们所做的是问题推q到另一个类中。但是用该解决ҎQ我们可通过改变Part对象Q在q行期间动态地来设定计L{略?br>
14.另一个解x案是使每个ConcretePart从数据库或属性文件中获取其当前的h?br>
单选法?br>
单选法则(the Single Choice PrincipleQ是OCP的一个推论?br>
无论在什么时候,一个Y件系l必L持一l备选项Q理x况下Q在pȝ中只能有一个类能够知道整个的备选项集合?br>
法则4QLiskov替换法则QLSPQ?br>
使用指向基类Q超c)的引用的函数Q必能够在不知道具体派生类Q子c)对象cd的情况下使用它们?br>
[ Function Thar Use Referennces To Base(Super) Classes Must Be Able To Use Objects
Of Derived(Sub) Classes Without Knowing It ]
Liskov替换法则
1.显而易见,Liskov替换法则QLSPQ是Ҏ我所熟知?多?而得出的?br>
2.例如Q?br>
ҎdrawShape应该可与Sharp类的Q何子cM起工作(或者,若Sharp为Java接口Q则该方法可与Q何实CSharp接口的类一起工作)
但是当我们在实现子类时必要谨慎对待Q以保我们不会无意中违背了LSP?/p>
3.若一个函数未能满LSPQ那么可能是因ؓ它显式地引用了超cȝ一些或所有子cR这L函数也违背了OCPQ因为当我们创徏一个新的子cLQ会不得不进行代码的修改?br>
LSPCZ
1. 考虑下面Rectanglec:
![]()
2.现在QSquarecM如何呢?昄Q一个正方Ş是一个四边ŞQ因此Squarecd该从RectanglecL生而来Q对否?让我们看一看!
3.观察可得Q?br>
a.正方形不需要将高和宽都作ؓ属性,但是M它将l承自Rectangle。因此,每一个Square对象会浪费一点内存,但这q不是一个主要问题?br>
b.l承而来的setWidth()和setHeight()Ҏ对于Square而言q真正地适合Q因Z个正方Ş的高和宽是相同。因此我们将需要重写setWidth()和setHeight()Ҏ。不得不重写q些单的Ҏ有可能是一U不恰当的承用方式?/p>
3.Squarecd下:
![]()
4. 看v来都q不错。但是让我们验一下!
![]()
5. 试E序输出Q?
6.看上d像我们违背了LSPQ?/p>
7.q里的问题出在哪里呢Q编写testLsp()Ҏ的程序员做了一个合理的假设Q即改变Rectangle的宽而保持它的高不变?br>
8.在将一个Square对象传递给q样一个方法时产生了问题,昄是违背了LSP
9.Square和RectanglecL怺一致和合法的。尽程序员对基cM了合理的假设Q但其所~写的方法仍然会D设计模型的失败?br>
10.不能孤立地去看待解决ҎQ必L据设计用h做的合理假设来看待它们?/p>
11. 一个数学意义上的正方Ş可能是一个四边ŞQ但是一个Square对象不是一个Rectangle对象Q因Z个Square对象的行Z一个Rectangle对象的行为是不一致的Q?br>
12.从行Z来说Q一个Square不是一个RectangleQ一个Square对象与一个Rectangle对象之间不具有多态的特征?br>
ȝ
1.Liskov替换法则QLSPQ清楚地表明了ISA关系全部都是与行为有关的?br>
2.Z保持LSPQƈ与开放-闭法则一PQ所有子cdȝ合用基cȝclient所期望的行为?br>
3.一个子cd不得h比基cdQbase typeQ更多的限制Q可能这对于基类型来说是合法的,但是可能会因背子cd的其中一个额外限Ӟ从而违背了LSPQ?br>
4.LSP保证一个子cLL能够被用在其基类可以出现的地方!