设计模式概念与作用：

设计模式是一套被反复使用的、多数人知晓、经过分类编目的优秀代码设计经验的总结。特定环境下特定问题的处理方法。
1）重用设计和代码 重用设计比重用代码更有意义，自动带来代码重用
2）提高扩展性 大量使用面向接口编程，预留扩展插槽，新的功能或特性很容易加入到系统中来
3）提高灵活性 通过组合提高灵活性，可允许代码修改平稳发生，对一处修改不会波及到其他模块
4） 提高开发效率 正确使用设计模式，可以节省大量的时间

---

设计模式六大原则：

1.单一职责原则
2.里氏替换原则
3.依赖倒置原则
4.接口隔离原则
5.迪米特法则
6.开闭原则

---

单一职责原则：

单一原则（Single Responsibility Principle）：一个类或者一个方法只负责一项职责，尽量做到类的只有一个行为原因引起变化； 

遵循单一职责的优点：
1)降低类的复杂度，一个类只负责一项职责。
2)提高类的可读性，可维护性
3)降低变更引起的风险。

---

案例说明：

问题：如果类A负责两个不同职责：职责1，职责2，当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的力度分解为A1，A2

需求：有一个动物类，里面定义了一个在陆地奔跑的方法。并调用它

public class Animal {
    public void run(String aniaml){
        System.out.println(aniaml+"在陆地上奔跑");
    }
}

public class AnimalTest {

	public static void main(String[] args) {
		new Animal().run("老虎");
		new Animal().run("鲨鱼");
		new Animal().run("老鹰");
	}
}

老虎在陆地上奔跑
鲨鱼在陆地上奔跑
老鹰在陆地上奔跑

结果：第一条执行正确符合需求。第二行和第三行执行结果 显然不符合实际。

方案一：我们将Animal拆分。

public class LandAnimal {

	public void run(String aniaml){
        System.out.println(aniaml+"在陆地上奔跑");
    }
}

public class SeaAnimal {

	public void run(String aniaml){
        System.out.println(aniaml+"在海里游");
    }
}

public class AirAnimal {

	public void run(String aniaml){
        System.out.println(aniaml+"在空中飞");
    }
}

public class AnimalTest {

	public static void main(String[] args) {
		new LandAnimal().run("老虎");
		new SeaAnimal().run("鲨鱼");
		new AirAnimal().run("老鹰");
	}
}

老虎在陆地上奔跑
鲨鱼在海里游
老鹰在空中飞

优势：符合了业务逻辑，符合了单一职责原则

劣势：改动幅度大，不光拆分类，客户端的代码也要进行大幅度的改动

方案二：

public class Animal {
	
	public void runLand(String aniaml){
        System.out.println(aniaml+"在陆地上奔跑");
    }
	
	public void runSea(String aniaml){
        System.out.println(aniaml+"在海里游");
    }
	
	public void runAir(String aniaml){
        System.out.println(aniaml+"在空中飞");
    }
}

public class AnimalTest {

	public static void main(String[] args) {
		new Animal().runLand("老虎");
		new Animal().runSea("鲨鱼");
		new Animal().runAir("老鹰");
	}
}

老虎在陆地上奔跑
鲨鱼在海里游
老鹰在空中飞

优势：改动幅度小，包括客户端，完成了业务逻辑

劣势：违背了单一职责原则，但在方法级别上却是符合单一职责原则的。

---

总结：

本文所举的例子，只有一个方法，太简单了，实际应用中的类都要复杂的多，当需求更改需要修改类时，我们要遵循单一职责原则的好。