]]>
到底我们Z么要用设计模式呢Q这么多设计模式Z么要q么设计呢？Z么要提?Design Pattern"呢？Ҏ原因是ؓ了代码复用，增加可维护性。那么怎么才能实现代码复用呢？OO界有前辈的七大原则："开Q闭"原则(Open Closed Principal)、里氏代换原则、合成复用原则，依赖倒{原则Q接口隔d则，抽象c，q米Ҏ则。设计模式就是实Cq些原则Q从而达C代码复用、增加可l护性的目的?br />
1?开Q闭"原则
q些OOD原则的一个基矛_?开-闭原?(Open-Closed Principle OCP).q个原则最早是由Bertrand Meyer提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是?一个Y件实体应当对扩展开?对修改关?也就是说,我们在设计一个模块的时?应当使这个模块可以在不被修改的前提下被扩?换句话说是,应当可以在不必修Ҏ代码的情况下改变q个模块的行?
满OCP的设计给pȝ带来两个无可比拟的优?
1.通过扩展已有的Y件系l?可以提供新的行ؓ,以满_软g的新需?使变化中的Y件系l有一定的适应性和灉|?
2.已有的Y件模?特别是最重要的抽象层模块不能再修?q就使变化中的Y件系l有一定的E_性和延箋?
hq两个优点的软gpȝ是一个高层次上实C复用的系l?也是一个易于维护的pȝ.那么,我们如何才能做到q个原则?不能修改而可以扩?q个看v来是自相矛盾?其实q个是可以做到的,按面向对象的说法,q个是不允许更改系l的抽象?而允许扩展的是系l的实现?
解决问题的关键在:抽象?我们让模块依赖于一个固定的抽象?q样它就是不可以修改?同时,通过q个抽象体派?我们可以扩展此模块的行为功?如此,q样设计的程序只通过增加代码来变化而不是通过更改现有代码来变?前面提到的修改的副作用就没有?
"开-?原则如果从另外一个角度讲q?是所谓的"对可变性封装原?(Principle of Encapsulation of Variation, EVP).讲的是找C个系l的可变因素,之装h.在我们考虑一个系l的时?我们不要把关注的焦点攑֜什么会D设计发生变化?而是考虑允许什么发生变化而不让这一变化D重新设计.也就是说,我们要积极的面对变化,U极的包容变?而不是逃避.
2、里氏代换原?br />
指导我们如何LZ个extends(l承、派?l构?br /> 子类与父cȝ关系必须是is-AQ即Q子cddM场合都敢于大声宣U自pv?臛_)是一个父cR比如，假设某类l构Q?#8220;男h”?#8220;女h”?#8220;?#8221;z出来Q看h是满里氏代换原则的，因ؓ无论“男h”q是“女h”Q在M场合都是“?#8221;。这个原则大多数情况下，可以用现实世界中的概忉|思考，但Y件世界与昄世界毕竟有区别，比如Q书中的例子Q?#8220;正方形是不是矩Ş”问题?br /> 此外Q很多问题需要利用OO核心思想来灵z考虑Q还是书中的例子(我只说大概意思，可能与书中描q存在差?Q一个类l构Q?#8220;职工、普通职员、项目经理、科ѝ部?#8230;…”Q从“员工”cL生出来，从一般概忉|看还不错Q职工和部长都是员工嘛，但这里隐含问题，现实世界中，普通职员可能变成项目经理，但Y件世界中Q普通职员和目l理被规划成两个cMQ于是一个普通职员instance是很隑֏成项目经理instance的，q说明我们把昄世界映射Y件世界时Q出C问题。更加合理的做法是，把这些职?角色)抽象出来Q比如叫?#8220;职务”c?interface/abstract class)Q所有职务从其派生，员工cR职务类是关联关p，M一个员工实例都一个职务实例作为它的属性，q样对了，员工的职务是可以变化的。实现这个重构的依据Q是OO中的装变化思想Q以及从中演化出来的依赖倒换原则、合?聚合复用原则?br /> 但凡涉及到extendsl构的设计模式都W合着里氏代换原则Q?br /> {略模式Q一l算法，把他们封装成对象Q之可以互换（满同一接口Q即都is-Aq个接口Q?br /> 合成模式QLeaf和Composite都is-A ComponentQ于是才可能方便地层层嵌套?br /> 代理模式QProxy与RealSubject都is-A父类SubjectQ于是可以插入代理，完成附加功能?br />
3、合成复用原?br />
合成和聚合都是关联的ҎU类。聚合表C?#8220;拥有”关系或整体与部分的关p；而合成则是用来表CZU强的多?“拥有”。在一个合成的关系里，部分和整体的生命周期是一L。一个合成的新的对象完全用又对其他组成部分的支配权。包括他们的创徏和灭。组合而成的对象对l成部分的内存分配、内存释放有l对的责仅R?q一步讲。一个合成的多重性不能超q?Q换a之，一个合成的关系中，部分对象不能于另一个合成关pd象共享?br /> 合成通常理解为：值的聚合。而聚合则是：引用的聚合?br /> 合成和聚合是已有的对象U_到新的对象中Q之成为新对象的一部分Q因此新的对象可以调用已由对象的功能。达到复用的目的?br />
优点Q?br />
l 新对象存取成分对象的唯一Ҏ是通过成分对象的接口?br />
q种复用是黑复用，隐藏了成分对象的内部l节?br />
q种复用支持包装?br />
q种复用依赖性较。（耦合度低Q?br />
每一个新cd以将焦点集中在一个Q务上?br />
q种复用可以在运行时动态进行。新对象可以动态引用于成分对象cd的子对象?br />
~点是Q?br />
通过q种复用建造的pȝ通常会有较多的对象需要管理?br />
“合成聚合复用可以替代l承复用完成M功能?#8221;
4 依赖倒{原则
很具体地指导我们Ҏ象类(接口)、实现类的用?br /> 依赖于抽象的实体(interface/abstract class)Q才能够更具有可插入?但凡实现既有接口的实现类实例都可以在依赖此接口的地方以此接口实例的角色插入进?Q更Ҏ满Open- Close原则(抽象的层ơ不变化、实现的层次׃使用不同的类来封装不同的变化Q于是可以在增加新类作ؓ扩展的同时不需要修改已有实现类)?br />
5 接口隔离原则
?义：使用多个专门的接口要比用单一的L口要好！
从客L角度上看Q一个类对另外一个类的依赖性应当是建立在最的接口之上?br /> 接口的划分直接带来类型的划分?br /> 目标是不向客户cL供不必要的行为?br /> 6 抽象c?br />
抽象cM会有实例Q一般作为父cMؓ子类l承Q一般包含这个系的共同属性和Ҏ?br />
注意Q好的承关pMQ只有叶节点是具体类Q其他节点应该都是抽象类Q也是说具体类
是不被承的。将可能多的共同代码放到抽象类中?br />
7 q米Ҏ?br />
用于解开cM间的不必要的耦合?#8220;不要与陌生h说话”。说hҎQ实际操作的时候很可能出现些无所适从的问题，而解开cM间的耦合是比较重要的Q目前我们设计类的时候，增加属性、增加对其他cȝ调用都比较随意，不太好?br /> q米Ҏ则要求：一个对象应当对其他对象有尽可能的了解。几U其他的表述Q只与你直接的朋友通信、不要跟“陌生?#8221;说话Q冯q征Q）
每个软g单位对其他单位都h最的知识Q而且局限于那些与本单位密切相关的Y件单位?br /> 狭义q米Ҏ?规定了谁是Friends、谁是Stranger。Friends圈子包括Q?br /> 当前对象自nQthisQ、Instance fieldQ如果field是Map、List{容器类型，则容器内的对象也是朋友）、当前对象创建的对象Q调用其构造方法）、当前对象方法的参数对象?br /> 只跟Friends说话Q跟Stranger说的话由Friends转述?br /> 狭义q米Ҏ则的弊端Q传递间接调用的方法太多！解决办法Q遵循依赖倒换原则做些折衷处理Q让对象依赖于Stranger的抽象层。虽然没有完全断开耦合Q至降低了耦合?br />
ȝQ?软gpȝ中，一个模块设计的好不好最主要、最重要的标志，是该模块在多大E度上将自己的内部数据和其他实现l节隐藏h。一个设计好的模块可以将它所有的实现l节隐藏hQ很d的将提供l外界的API和自q实现分离开来。这样一来模块于模块之间的通信仅仅通过彼此的APIQ而不理会模块内部的工作细节。这便是Q?#8220;信息的隐?#8221;?br />
]]>