设计模式的六大原则实例.doc

一、设计模式的六大原则1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类。开闭原则是面向对象的可复用设计的第一块基石。开闭原则的关键是抽象化。2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。面向对象的设计关注的是对象的行为，它是使用“行为”来对对象进行分类的，只有行为一致的对象才能抽象出一个类来。我经常说类的继承关系就是一种“Is-A”关系，实际上指的是行为上的“Is-A”关系，可以把它描述为“Act-As”。3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。5、迪米特法则（最少知道原则）（Demeter Principle）最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。6、合成复用原则（Composite Reuse Principle）合成/聚合复用原则是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。合成(Composition)和聚合(Aggregation)都是关联(Association)的特殊种类。原则是尽量使用合成/聚合的方式，而不是使用继承。11.开闭原则实例Fruit接口：抽象产品Orange类：实现fruit接口，具体产品Apple类：实现Fruit接口，具体产品Gardener接口：抽象工厂AppleGardener类：实现Gardener接口，具体工厂，分管apple生产OrangeGardener类：实现Gardener接口，具体工厂，分管orange生产package com.zky.www.factory;public interface Fruit /水果接口public void plant();public void grow();public void harvest();public class Apple implements Fruit /苹果实现水果接口public void grow() System.out.println(apple is growing!);public void harvest() System.out.println(apple is harvesting!);public void plant() System.out.println(apple is planting!);public class Orange implements Fruit /桔子实现水果接口public void grow() System.out.println(orange is growing!);public void harvest() System.out.println(orange is harvesting!);public void plant() System.out.println(orange is planting!);public interface Gardener /园丁接口public Fruit getFruit();public class AppleGardener implements Gardener Overridepublic Fruit getFruit() return new Apple();public class OrangeGradener implements Gardener Overridepublic Fruit getFruit() return new Orange();public class Client public static void main(String args) Gardener g1=new AppleGardener();Apple apple=(Apple) g1.getFruit();apple.harvest();22、里氏代换原则实例正方形不是长方形package com.zky.www.liskov;public class Rectangle private double width;private double height;public Rectangle()public Rectangle(double width, double height) super();this.width = width;this.height = height;public double getWidth() return width;public void setWidth(double width) this.width = width;public double getHeight() return height;public void setHeight(double height) this.height = height;package com.zky.www.liskov;public class Square extends Rectangle private double side;public Square(double side) super();this.side = side;public double getSide() return side;public void setSide(double side) this.side = side;package com.zky.www.liskov;public class SmartTest public void resize(Rectangle r)while (r.getHeight()=r.getWidth()r.setWidth(r.getWidth()+1);33、依赖倒转原则实例publicclassBenz /汽车肯定会跑 publicvoidrun() System.out.println(奔驰汽车开始运行.); publicclassDriver /司机的主要职责就是驾驶汽车 publicvoiddrive(Benz benz) benz.run(); publicclassClient publicstaticvoidmain(String args) Driver zhangSan = newDriver(); Benz benz = newBenz(); /张三开奔驰车 zhangSan.drive(benz); 上面实例，司机张三只能开奔驰车，不能开其他车，因此设计出了问题，改正如下。publicinterfaceIDriver /是司机就应该会驾驶汽车 publicvoiddrive(ICar car); publicclassDriver implementsIDriver /司机的主要职责就是驾驶汽车 publicvoiddrive(ICar car) car.run(); publicinterfaceICar /是汽车就应该能跑 publicvoidrun(); publicclassBenz implementsICar /汽车肯定会跑 publicvoidrun() System.out.println(奔驰汽车开始运行.); publicclassBMW implementsICar /宝马车当然也可以开动了 publicvoidrun() System.out.println(宝马汽车开始运行.); 在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象，Client的实现过程如下：public class Client public static void main(String args) IDriver zhangSan = new Driver();ICar benz = new Benz();/张三开奔驰车zhangSan.drive(benz); Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的显示类型是IDriver，benz的显示类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如new Driver()和new Benz()等，如何解释？确实如此，zhangSan的显示类型是IDriver，是一个接口，是抽象的，非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以。注意在Java中，只要定义变量就必然要有类型，一个变量可以有两个类型：显示类型和真实类型，显示类型是在定义的时候赋予的类型，真实类型是对象的类型，如zhangSan的显示类型是IDriver，真实类型是Driver。44.接口隔离原则public interface IPettyGirl /要有姣好的面孔public void goodLooking();/要有好身材public void niceFigure();/要有气质public void greatTemperament();public class PettyGirl implements IPettyGirl private String name;/美女都有名字public PettyGirl(String name) this. name=name; /脸蛋漂亮public void goodLooking() System. out.println(this. name + -脸蛋很漂亮!); /气质要好public void greatTemperament() System. out.println(this. name + -气质非常好!); /身材要好public void niceFigure() System. out.println(this. name + -身材非常棒!); public abstract class AbstractSearcher protected IPettyGirl pettyGirl;public AbstractSearcher(IPettyGirl _pettyGirl) this.pettyGirl = _pettyGirl; /搜索美女，列出美女信息public abstract void show();public class Searcher extends AbstractSearcherpublic Searcher(IPettyGirl _pettyGirl) super(_pettyGirl); /展示美女的信息public void show() System. out.println(-美女的信息如下： -); /展示面容 super. pettyGirl.goodLooking(); /展示身材super. pettyGirl.niceFigure(); /展示气质 super. pettyGirl.greatTemperament(); public class Client /搜索并展示美女信息public static void main(String args) /定义一个美女 IPettyGirl yanYan = new PettyGirl(嫣嫣); AbstractSearcher searcher = new Searcher(yanYan); searcher.show(); 如果星探想找有内在气质的，不找外形漂亮的，怎么办？看来IPettyGirl接口功能有些臃肿，因此把原 IPettyGirl 接口拆分为两个接口，一种是外形美的美女 IGoodBodyGirl，这类美女的特点就是脸 蛋和身材极棒，超一流，但是没有审美素质，比如随地吐痰，出口就是脏话，文化程度比较低； 另外一种是气质美的美女 IGreatTemperamentGirl，谈吐和修养都非常高。我们从一个比较臃肿的接口拆分 成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后是要外形美的美女还是气质美的美女 都可以轻松的通过 PettyGirl 定义。我们先看两种类型的美女接口：public interface IGoodBodyGirl /要有姣好的面孔public void goodLooking();/要有好身材public void niceFigure();public interface IGreatTemperamentGirl /要有气质public void greatTemperament();实现类没有改变，只是实现类两个接口，源码如下：public class PettyGirl implements IGoodBodyGirl,IGreatTemperamentGirl private String name;/美女都有名字public PettyGirl(String _name) this. name=_name; /脸蛋漂亮public void goodLooking() System. out.println(this. name + -脸蛋很漂亮!); /气质要好public void greatTemperament() System. out.println(this. name + -气质非常好!); /身材要好public void niceFigure() System. out.println(this. name + -身材非常棒!); 通过这样的改造以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。当然你可能 要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个 IGoodBody 接口还是要修改的呀， 确实是，但是设计时有限度的，不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。 以上把一个臃肿的接口变更为两个独立的接口依赖的原则就是接口隔离原则，让 AbstractSearcher 依 赖两个专用的接口比依赖一个综合的接口要灵活。接口是我们设计时对外提供的契约，通过分散定义多个 接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。55.迪米特法则如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另外一个类的某一个方法，可以通过第三者转发这个调用。参考下例，Someone、Friend和Stranger三个类。publicclassSomeonepublicvoidoperation1(Friendfriend)Strangerstranger=vide();stranger.operation3();所以Someone和Friend是朋友类（直接通讯的类）。同理，Friend类持有一个Stranger类的私有对象，他们是朋友类：publicclassFriendprivateStrangerstranger=newStranger();publicvoidoperation2()publicStrangerprovide()returnstranger;在这里，Someone类和Stranger类不是朋友类，但Someone类却通过Friend类知道了Stranger类的存在，这显然违反迪米特法则。现在，我们对Someone和Friend类进行重构。首先在Friend类里添加一个方法，封装对Stranger类的操作：publicclassFriendprivateStrangerstranger=newStranger();publicvoidoperation2()publicStrangerprovide()returnstranger;publicvoidforward()stranger.operation3();然后，我们重构Someone的operation1方法，让其调用新提供的forward方法：publicclassSomeonepublicvoidoperation1(Friendfriend)friend.forward();现在Someone对Stranger的依赖完全通过Friend隔离，这样的结构已经符合狭义迪米特法则了。仔细观察上述结构，会发现狭义迪米特法则一个明显的缺点：会在系统里造出大量的小方法，散落在系统的各个角落。这些方法仅仅是传递间接的调用，因此与系统的商务逻辑无关，当设计师试图从一张类图看出总体的框架时，这些小的方法会造成迷惑和困扰。遵循迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。结合依赖倒转原则，我们对代码进行如下重构来解决这个问题，首先添加一个抽象的Stranger类，使Someone依赖于抽象的“Stranger”角色，而不是具体实现：publicabstractclassAbstractStrangerabstractvoidoperation3();然后，让Stranger从该类继承：publicclassStrangerextendsAbstractStrangerpublicvoidoperation3()随后，我们重构Someone使其依赖抽象的Stranger角色：publicclassSomeonepublicvoidoperation1(Friendfriend)AbstractStrangerstranger=vide();stranger.operation3();最后，我们重构Friend的provide方法，使其返回抽象角色：publicclassFriendprivateStrangerstranger=newStranger();publicvoidoperation2()publicAbstractStrangerprovide()returnstranger;现在，AbstractStranger成为Someone的朋友类，而Friend类可以随时替换掉AbstractStranger的实现类，Someone不再需要了解Stranger的内部实现细节。下图是重构后的UML类图：在将迪米特法则运用到系统的设计中时，应注意的几点： 在类的划分上，应该创建有弱耦合的类； 在类的结构设计上，每一个类都应当尽量降低成员的访问权限； 在类的设计上，只要有可能，一个类应当设计成不变类； 在对其他类的引用上，一个对象对其它对象的引用应当降到最低； 尽量降低类的访问权限； 谨慎使用序列化功能； 不要暴露类成员，而应该提供相应的访问器(属性)。66、合成复用原则实例（1）聚合用来表示“拥有”关系或者整体与部分的关系。代表部分的对象有可能会被多个代表整体的对象所共享，而且不一定会随着某个代表整体的对象被销毁或破坏而被销毁或破坏，部分的生命周期可以超越整体。例如，班级和学生，当班级删除后，学生还能存在，学生可以被培训机构引用。class Student private String sName;class Classes private Student student; public Classes(Student student) this.student=student; （2）合成用来表示一种强得多的“拥有”关系。在一个合成关系里，部分和整体的生命周期是一样的。一个合成的新对象完全拥有对其组成部分的支配权，包括它们的创建和湮灭等。使用程序语言的术语来说，合成而成的新对象对组成部分的内存分配、内存释放有绝对的责任。一个合成关系中的成分对象是不能与另一个合成关系共享的。一个成分对象在同一个时间内只能属于一个合成关系。如果一个合