、设计模式的六大原则
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 Orangeimplements 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 AppleGardenerimplements Gardener {
@Override
public Fruit getFruit() {
return new Apple();
}
}
public class OrangeGradenerimplements Gardener { @Override public 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 Squareextends 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、依赖倒转原则实例
public class Benz {
// 汽车肯定会跑public void run() {
System.out.println(" 奔驰汽车开始运行...");
}
}
public class Driver {
// 司机的主要职责就是驾驶汽车
public void drive(Benz benz){ benz.run();
}
}
public class Client {
public static void main(String[] args) {
Driver zhangSan = new Driver();
Benz benz = new Benz();
// 张三开奔驰车
zhangSan.drive(benz);
}
}
上面实例，司机张三只能开奔驰车，不能开其他车，因此设计出了问题，改正如下。public interface IDriver {
// 是司机就应该会驾驶汽车
public void drive(ICar car);
public class Driver implements IDriver{ // 司机的主要职责就是驾驶汽车public void drive(ICar car){ car.run();
}
}
public interface ICar {
// 是汽车就应该能跑
public void run();
}
public class Benz implements ICar{
// 汽车肯定会跑
public void run(){
System.out.println(" 奔驰汽车开始运行...");
}
}
public class BMWimplements ICar{
// 宝马车当然也可以开动了
public void run(){
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 AbstractSearcher{
public 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( Stri ng[] args) {
//定义一个美女
IPettyGirl yanYan = n ewPettyGirl(" 嫣嫣");
AbstractSearcher searcher = n ewSearcher(ya nYan);
searcher.show();
}
}
如果星探想找有内在气质的，不找外形漂亮的，怎么办？看来IPettyGirl 接口功能有些臃肿，因此把原IPettyGirl 接口拆分为两个接口，一种是外形美的美
女IGoodBodyGirl，这类美女的特点就是脸蛋和身材极棒，超一流，但是没有
审美素质，比如随地吐痰，出口就是脏话，文化程度比较低；另外一种是气质
美的美女IGreatTemperamentGirl ，谈吐和修养都非常高。我们从一个比较臃肿的接口拆分成了两个专门的接口，灵活性提高了，可维护性也增加了，不管以后是要外形美的美女还是气质美的美女都可以轻松的通过PettyGirl 定义。我们先看两种类型的美女接口：
public in terface IGoodBodyGirl {