本系列主要摘自：左潇龙的博客园
学习设计模式的好处：
可以被反复使用、多数人知晓、分类编目、代码设计经验
增强系统健壮性、可扩展性。改变思维
设计模式分类：
设计模式按照使用场景可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。
- 创建型模式（Creational Patterns）
对对象的实例化过程进行抽象，这使得一个系统可以不用关心这些对象是如何创建，组合，呈现的，对于类创建模式来说通过使用继承改变实例化的类，对于对象创建模式来说通过使用代理来实例化所需要的对象。 - 结构型模式（Structural Patterns）
通过对多个类和对象进行组合得到复杂结构的类，一般使用继承继承或者成员变量引用形式来实现。 - 行为型模式（Behavioral Patterns）
行为模式不仅表达了对象和类，还表达了他们之间的交互，涉及到了对象和算法的分配。
六大原则：
1. 单一职责原则：尽量让一个类只做一个功能（尽量拆分的很细）
例子：
不好的写法：把读取文件和计算写到了一起
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
public class Calculator {
public int add() throws NumberFormatException, IOException{
File file = new File("E:/data.txt");
BufferedReader br = new BufferedReader(new FileReader(file));
int a = Integer.valueOf(br.readLine());
int b = Integer.valueOf(br.readLine());
return a+b;
}
public static void main(String[] args) throws NumberFormatException, IOException {
Calculator calculator = new Calculator();
System.out.println("result:" + calculator.add());
}
}
好的写法：把读文件和计算的方法分开
我们分离出来一个类用来读取数据，来看Reader。
package com.test;
import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;
public class Reader {
int a,b;
public Reader(String path) throws NumberFormatException, IOException{
BufferedReader br = new BufferedReader(new FileReader(new File(path)));
a = Integer.valueOf(br.readLine());
b = Integer.valueOf(br.readLine());
}
public int getA(){
return a;
}
public int getB(){
return b;
}
}
下面是我们单独的计算器类。
package com.test;
import java.io.IOException;
public class Calculator {
public int add(int a,int b){
return a + b;
}
public static void main(String[] args) throws NumberFormatException, IOException {
Reader reader = new Reader("E:/data.txt");
Calculator calculator = new Calculator();
System.out.println("result:" + calculator.add(reader.getA(),reader.getB()));
}
}
2. 里氏替换原则：一个子类应该可以替换掉父类并且可以正常工作。
简单来说的话就是，当程序在使用父类能正常工作的时候，在替换成其子类的时候程序也是可以正常工作的。这就要求了子类在重写父类的方法的时候要能够完全替代父类中被重写的方法。
这个原则常常不受待见，因为往往我们在违反这个原则的时候可以做一些更加灵活设计。虽然可能会埋下“坑”。
例子：
public class Parent {
public void method(){
System.out.println("parent method");
}
}
public class SubClass extends Parent{
//结果某一个子类重写了父类的方法，说不支持该操作了
public void method() {
throw new UnsupportedOperationException();
}
}
//某一个类
public class SomeoneClass {
//有某一个方法，使用了一个父类类型
public void someoneMethod(Parent parent){
parent.method();
}
}
//客户端代码
public class Client {
public static void main(String[] args) {
SomeoneClass someoneClass = new SomeoneClass();
someoneClass.someoneMethod(new Parent());
someoneClass.someoneMethod(new SubClass());
}
}
3. 接口隔离原则：和单一职责比较像，要求接口的最小化，定义一个接口的时候应该拥有尽量少的方法.
如果一个接口里有大量的方法是不应该出现在这个接口中的，那么我们很容易就出现某个实现这个接口的类会有很多方法是空着的。会给使用的人造成一种假象，实现类拥有接口中所有的方法，但事实上却没有得到想要的结果。
比如把手机要抽象成一个接口，需要给手机一些功呢？
public interface Mobile {
public void call();//手机可以打电话
public void sendMessage();//手机可以发短信
public void playGames();//玩游戏？
}
比如打电话，发短信。但是你要给手机定义一个玩游戏通功能呢？这样就是不符合了接口隔离原则，因为不是所有的手机需要可以玩游戏。
但如果我们要定义一个智能手机的接口，就可以加上这个playGames接口了。
4. 依赖倒置原则：高层模块不应该依赖于低层次的模块，他们应该依赖于抽象。抽象不应该依赖于实现，具体实现应该依赖于抽象
上面的介绍是官方的解释，我自己的理解的依赖导致原则就是在程序的设计或者说是实现上不应该依赖于具体的实现，能抽象就抽象出来，然后依赖这个抽象。如果不这么做的话，我们在修改底层程序的时候会严重的影响调用底层程序的上层程序，这要就会导致复用性降低。如果我们使用抽象，让上层程序依赖于一个抽象的接口，虽然有可能底层实现的细节在不断的变动，但是只要抽象不变，上层就不需要变。降低了耦合度。
5. 迪米特原则：也称最小知道原则，即一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。
简单来说就是高内聚，对外不要暴露太多的细节。这样耦合度就会降低
6. 开闭原则：对修改关闭，对扩展开发
就是任何改变都不要修改原来的代码，只要加入一些新的实现就能实现需求。
这个原则是上面5个原则的总纲领，上面的5个原则的目的就是为了对修改关闭，对扩展开发。
