设计模式基础

在介绍具体的设计模式之前,先介绍一些基础知识,主要以JAVA语言为例.

一:UML简介

对一个大型软件系统,没有UML这样的设计图,而直接进行编程是不可想像的.好比建造一栋大厦时不使用设计图纸而直接叫工人去砌砖一样.

UML是图标式软件设计语言,主要用来描述系统各部分之间的结构,行为.

设计模式介绍中主要用到的图包括

类图





类之间的关系:

1.Generalization(一般化)



2:Association(关联)



3:Dependency(依赖)



序列图

二:OO principle

面向对象开发的原则:在设计模式背后的原则,对设计模式的基础.

Open-Closed Principle(开闭原则):

Software entries should open for extension,and close for modification.

例如一个JAVA的基础类,当新的版本要增加或修改功能时,能够不修改接口(如果修改接口,客户的程序都得修改)的情况下完成.

Liskov Subtitution Principle里氏代换原则(LSP)

讲的是基类与子类之间的关系,基类能出现的地方子类必须也能出现.

长方形与正方形的例子,如果把正方形当成长方形的子类,长方形中有一个addWidth的方法,增加宽度,

显然不适应正方形.

Dependence Inverstion Principle依赖倒转原则(DIP)

Depend upon abstractions.Do not depend upon concrete classes.

即面向抽象编程，而不是面向具体编程。

具体指导原则

1:不能有具体类的实例变量。

2:不能从具体类继承。

3:不要覆盖基类中已经实现的方法。

Interface Segregation接口隔离原则(ISP)

不要把实现不同功能的接口放在一个类中。

Composite/Aggregate Reuse Principle 合成聚合复用原则(CARP)

代码复用时,即一个类要用到另一个类的功能时,尽量使用合成,即用另一个类的实例变量,而不用继承.

只有从分类学角度确认一个类确实为另一个的子类,此子类具有父类一切方法和属性时才用继承.

即分析HAS-a 还是IS-a的关系.如反例:JAVA中的Properties类继承了Hashtable,实际上Properties只是用到了Hashtable中的部分功能,两者是HAS-a的关系,而不是IS-a的关系.

Least Knowledge Principle 最少知识原则(LKP)

Only talk to your immediate friends.

朋友：当前对象，对象参数，实例变量，当前对象所创建的对象。




public Client...{




public float fun1(Friend friend)




...{


return friend.getStranger().fun3();//不满足LKP


}


}


//改造




public Client...{


pubic float fun1(Friend friend)




...{


return friend.strangerFun3();


}


}




public Friend




...{


private Stranger stranger;


public float strangerFun3()




...{


return stranger.fun3();


}


}
//经过这样改造后，Client和Stranger的直接关联去掉了，这样如果Stranger类需要修改的话仅仅影响到这个类的朋友，而不会影响到其他部分，降低了系统内部的耦合度。

Facade，Mediator模式是此原则的应用。

三:OO basic:

JAVA具体实现的基础

Abstraction(抽象) :依赖抽象，而不要依赖具体，因为抽象相对具体来说是稳定的。

Encapsulate(封装) :把易变的东西封装起来。

Inheritance(继承)

Polymorphism(多态)