设计模式的六大原则实例.docx
《设计模式的六大原则实例.docx》由会员分享，可在线阅读，更多相关《设计模式的六大原则实例.docx（22页珍藏版）》请在冰豆网上搜索。
设计模式的六大原则实例
一、设计模式的六大原则
1、开闭原则（OpenClosePrinciple）
开闭原则就是说对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：
为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类。
开闭原则是面向对象的可复用设计的第一块基石。
开闭原则的关键是抽象化。
2、里氏代换原则（LiskovSubstitutionPrinciple）
里氏代换原则（LiskovSubstitutionPrincipleLSP）面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
面向对象的设计关注的是对象的行为，它是使用“行为”来对对象进行分类的，只有行为一致的对象才能抽象出一个类来。
我经常说类的继承关系就是一种“Is-A”关系，实际上指的是行为上的“Is-A”关系，可以把它描述为“Act-As”。
3、依赖倒转原则（DependenceInversionPrinciple）
这个是开闭原则的基础，具体内容：
真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（InterfaceSegregationPrinciple）
这个原则的意思是：
使用多个隔离的接口，比使用单个接口要好。
还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。
所以上文中多次出现：
降低依赖，降低耦合。
5、迪米特法则（最少知道原则）（DemeterPrinciple）
最少知道原则，就是说：
一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（CompositeReusePrinciple）
合成/聚合复用原则是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。
合成（Composition）和聚合（Aggregation）都是关联（Association）的特殊种类。
原则是尽量使用合成/聚合的方式，而不是使用继承。
11.开闭原则实例
Fruit接口：
抽象产品
Orange类：
实现fruit接口，具体产品
Apple类：
实现Fruit接口，具体产品
Gardener接口：
抽象工厂
AppleGardener类：
实现Gardener接口，具体工厂，分管apple生产
OrangeGardener类：
实现Gardener接口，具体工厂，分管orange生产
packagecom.zky.;
publicinterfaceFruit{//水果接口
publicvoidplant（）;
publicvoidgrow（）;
publicvoidharvest（）;
}
publicclassAppleimplementsFruit{//苹果实现水果接口
publicvoidgrow（）{
System.out.println（"appleisgrowing!
"）;
}
publicvoidharvest（）{
System.out.println（"appleisharvesting!
"）;
}
publicvoidplant（）{
System.out.println（"appleisplanting!
"）;
}
}
publicclassOrangeimplementsFruit{
//桔子实现水果接口
publicvoidgrow（）{
System.out.println（"orangeisgrowing!
"）;
}
publicvoidharvest（）{
System.out.println（"orangeisharvesting!
"）;
}
publicvoidplant（）{
System.out.println（"orangeisplanting!
"）;
}
}
publicinterfaceGardener{//园丁接口
publicFruitgetFruit（）;
}
publicclassAppleGardenerimplementsGardener{
@Override
publicFruitgetFruit（）{
returnnewApple（）;
}
}
publicclassOrangeGradenerimplementsGardener{
@Override
publicFruitgetFruit（）{
returnnewOrange（）;
}
}
publicclassClient{
publicstaticvoidmain（String[]args）{
Gardenerg1=newAppleGardener（）;
Appleapple=（Apple）g1.getFruit（）;
apple.harvest（）;
}
}
22、里氏代换原则实例
正方形不是长方形
packagecom.zky.;
publicclassRectangle{
privatedoublewidth;
privatedoubleheight;
publicRectangle（）{}
publicRectangle（doublewidth,doubleheight）{
super（）;
this.width=width;
this.height=height;
}
publicdoublegetWidth（）{
returnwidth;
}
publicvoidsetWidth（doublewidth）{
this.width=width;
}
publicdoublegetHeight（）{
returnheight;
}
publicvoidsetHeight（doubleheight）{
this.height=height;
}
}
packagecom.zky.;
publicclassSquareextendsRectangle{
privatedoubleside;
publicSquare（doubleside）{
super（）;
this.side=side;
}
publicdoublegetSide（）{
returnside;
}
publicvoidsetSide（doubleside）{
this.side=side;
}
}
packagecom.zky.;
publicclassSmartTest{
publicvoidresize（Rectangler）
{
while（r.getHeight（）<=r.getWidth（））
{
r.setWidth（r.getWidth（）+1）;
}
}
}
33、依赖倒转原则实例
public class Benz{
//汽车肯定会跑
public void run（）{
System.out.println（"奔驰汽车开始运行..."）;
}
}
public class Driver{
//司机的主要职责就是驾驶汽车
public void drive（Benzbenz）{
benz.run（）;
}
}
public class Client{
public static void main（String[]args）{
DriverzhangSan=new Driver（）;
Benzbenz=new Benz（）;
//张三开奔驰车
zhangSan.drive（benz）;
}
}
上面实例，司机张三只能开奔驰车，不能开其他车，因此设计出了问题，改正如下。
public interface IDriver{
//是司机就应该会驾驶汽车
public void drive（ICarcar）;
}
public class Driverimplements IDriver{
//司机的主要职责就是驾驶汽车
public void drive（ICarcar）{
car.run（）;
}
}
public interface ICar{
//是汽车就应该能跑
public void run（）;
}
public class Benzimplements ICar{
//汽车肯定会跑
public void run（）{
System.out.println（"奔驰汽车开始运行..."）;
}
}
public class BMWimplements ICar{
//宝马车当然也可以开动了
public void run（）{
System.out.println（"宝马汽车开始运行..."）;
}
}
在业务场景中，我们贯彻“抽象不应该依赖细节”，也就是我们认为抽象（ICar接口）不依赖BMW和Benz两个实现类（细节），因此我们在高层次的模块中应用都是抽象，Client的实现过程如下：
publicclassClient{
publicstaticvoidmain（String[]args）{
IDriverzhangSan=newDriver（）;
ICarbenz=newBenz（）;
//张三开奔驰车
zhangSan.drive（benz）;
}
}
Client属于高层业务逻辑，它对低层模块的依赖都建立在抽象上，zhangSan的显示类型是IDriver，benz的显示类型是ICar，也许你要问，在这个高层模块中也调用到了低层模块，比如newDriver（）和newBenz（）等，如何解释？
确实如此，zhangSan的显示类型是IDriver，是一个接口，是抽象的，非实体化的，在其后的所有操作中，zhangSan都是以IDriver类型进行操作，屏蔽了细节对抽象的影响。
当然，张三如果要开宝马车，也很容易，我们只要修改业务场景类就可以。
注意在Java中，只要定义变量就必然要有类型，一个变量可以有两个类型：
显示类型和真实类型，显示类型是在定义的时候赋予的类型，真实类型是对象的类型，如zhangSan的显示类型是IDriver，真实类型是Driver。
44.接口隔离原则
publicinterfaceIPettyGirl{
//要有姣好的面孔
publicvoidgoodLooking（）;
//要有好身材
publicvoidniceFigure（）;
//要有气质
publicvoidgreatTemperament（）;
}
publicclassPettyGirlimplementsIPettyGirl{
privateStringname;
//美女都有名字
publicPettyGirl（Stringname）{
this.name=name;
}
//脸蛋漂亮
publicvoidgoodLooking（）{
System.out.println（this.name+"---脸蛋很漂亮!
"）;
}
//气质要好
publicvoidgreatTemperament（）{
System.out.println（this.name+"---气质非常好!
"）;
}
//身材要好
publicvoidniceFigure（）{
System.out.println（this.name+"---身材非常棒!
"）;
}
}
publicabstractclassAbstractSearcher{
protectedIPettyGirlpettyGirl;
publicAbstractSearcher（IPettyGirl_pettyGirl）{
this.pettyGirl=_pettyGirl;
}
//搜索美女，列出美女信息
publicabstractvoidshow（）;
}
publicclassSearcherextendsAbstractSearcher{
publicSearcher（IPettyGirl_pettyGirl）{
super（_pettyGirl）;
}
//展示美女的信息
publicvoidshow（）{
System.out.println（"--------美女的信息如下：
---------------"）;
//展示面容
super.pettyGirl.goodLooking（）;
//展示身材
super.pettyGirl.niceFigure（）;
//展示气质
super.pettyGirl.greatTemperament（）;
}
}
publicclassClient{
//搜索并展示美女信息
publicstaticvoidmain（String[]args）{
//定义一个美女
IPettyGirlyanYan=newPettyGirl（"嫣嫣"）;
AbstractSearchersearcher=newSearcher（yanYan）;
searcher.show（）;
}
}
如果星探想找有内在气质的，不找外形漂亮的，怎么办？
看来IPettyGirl接口功能有些臃肿，因此把原IPettyGirl接口拆分为两个接口，一种是外形美的美女IGoodBodyGirl，这类美女的特点就是脸蛋和身材极棒，超一流，但是没有审美素质，比如随地吐痰，出口就是脏话，文化程度比较低；另外一种是气质美的美女IGreatTemperamentGirl，谈吐和修养都非常高。
我们从一个比较臃肿的接口拆分成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后是要外形美的美女还是气质美的美女都可以轻松的通过PettyGirl定义。
我们先看两种类型的美女接口：
publicinterfaceIGoodBodyGirl{
//要有姣好的面孔
publicvoidgoodLooking（）;
//要有好身材
publicvoidniceFigure（）;
}
publicinterfaceIGreatTemperamentGirl{
//要有气质
publicvoidgreatTemperament（）;
}
实现类没有改变，只是实现类两个接口，源码如下：
publicclassPettyGirlimplementsIGoodBodyGirl,IGreatTemperamentGirl{
privateStringname;
//美女都有名字
publicPettyGirl（String_name）{
this.name=_name;
}
//脸蛋漂亮
publicvoidgoodLooking（）{
System.out.println（this.name+"---脸蛋很漂亮!
"）;
}
//气质要好
publicvoidgreatTemperament（）{
System.out.println（this.name+"---气质非常好!
"）;
}
//身材要好
publicvoidniceFigure（）{
System.out.println（this.name+"---身材非常棒!
"）;
}
}
通过这样的改造以后，不管以后是要气质美女还是要外形美女，都可以保持接口的稳定。
当然你可能要说了，以后可能审美观点再发生改变，只有脸蛋好看就是美女，那这个IGoodBody接口还是要修改的呀，确实是，但是设计时有限度的，不能无限的考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
以上把一个臃肿的接口变更为两个独立的接口依赖的原则就是接口隔离原则，让AbstractSearcher依赖两个专用的接口比依赖一个综合的接口要灵活。
接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。
55.迪米特法则
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。
如果其中的一个类需要调用另外一个类的某一个方法，可以通过第三者转发这个调用。
参考下例，Someone、Friend和Stranger三个类。
public class Someone
{
public void operation1（ Friend friend ）
{
Stranger stranger = friend.provide（） ;
stranger.operation3（） ;
}
}
所以Someone和Friend是朋友类（直接通讯的类）。
同理，Friend类持有一个Stranger类的私有对象，他们是朋友类：
public class Friend
{
private Stranger stranger = new Stranger（） ;
public void operation2（）{}
public Stranger provide（）
{
return stranger ;
}
}
在这里，Someone类和Stranger类不是朋友类，但Someone类却通过Friend类知道了Stranger类的存在，这显然违反迪米特法则。
现在，我们对Someone和Friend类进行重构。
首先在Friend类里添加一个方法，封装对Stranger类的操作：
public class Friend
{
private Stranger stranger = new Stranger（） ;
public void operation2（）{}
public Stranger provide（）
{
return stranger ;
}
public void forward（）
{
stranger.operation3（） ;
}
}
然后，我们重构Someone的operation1方法，让其调用新提供的forward方法：
public class Someone
{
public void operation1（ Friend friend ） {
friend.forward（） ; }
}
现在Someone对Stranger的依赖完全通过Friend隔离，这样的结构已经符合狭义迪米特法则了。
仔细观察上述结构，会发现狭义迪米特法则一个明显的缺点：
会在系统里造出大量的小方法，散落在系统的各个角落。
这些方法仅仅是传递间接的调用，因此与系统的商务逻辑无关，当设计师试图从一张类图看出总体的框架时，这些小的方法会造成迷惑和困扰。
遵循迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接关联。
但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。
结合依赖倒转原则，我们对代码进行如下重构来解决这个问题，首先添加一个抽象的Stranger类，使Someone依赖于抽象的“Stranger”角色，而不是具体实现：
public abstract class AbstractStranger
{
abstract void operation3（） ;
}
然后，让Stranger从该类继承：
public class Stranger extends AbstractStranger
{
public void operation3（） {}
}
随后，我们重构Someone使其依赖抽象的Stranger角色：
public class Someone
{
public void operation1（ Friend friend ） {
AbstractStranger stranger = friend.provide（） ;
stranger.operation3（） ; }
}
最后，我们重构Friend的provide方法，使其返回抽象角色：
public class Friend
{
private Stranger stranger = new Stranger（） ;
public void operation2（）{}
public AbstractStranger provide（）
{
return stranger ;
}
}
现在，AbstractStranger成为Someone的朋友类，而Friend类可以随时替换掉AbstractStranger的实现类，Someone不再需要了解Stranger的内部实现细节。
下图是重构后的UML类图：
在将迪米特法则运用到系统的设计中时，应注意的几点：
1在类的划分上，应该创建有弱耦合的类；
2在类的结构设计上，每一个类都应当尽量降低成员的访问权限；
3在类的设计上，只要有可能，一个类应当设计成不变类；
4在对其他类的引用上，一个对象对其它对象的引用应当降到最低；
5尽量降低类的访问权限；
6谨慎使用序列化功能；
7不要暴露类成员，而应该提供相应的访问器（属性）。
66、合成复
升级会员 