面向对象设计模式5大基本原则

“宇宙万物之中,没有一样东西能像思想那么顽固。” 一爱默生

首先明确模式是针对面向对象的，它的三大特性，封装、继承、多态。

面向对象设计模式有5大基本原则：单一职责原则、开发封闭原则、依赖倒置原则、接口隔离原则、Liskov替换原则。

而设计模式都是在面向对象的特性以及5大基本原则的基础上衍生而来的具体实现。

1、单一职责原则(SRP)：

　　1.1，SRP(Single Responsibilities Principle)的定义：就一个类而言，应该仅有一个引起它变化的原因。简而言之，就是功能要单一。
　　1.2，如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。(敏捷软件开发)
　　1.3，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。(敏捷软件开发)

小结：

单一职责原则可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这样导致职责依赖，相互之间就会产生原因，大大损伤其内聚性和耦合度。

2、开放-封闭原则(OCP)：

　　2.1，OCP(Open-Close Principle)的定义：就是说软件实体(类，方法等等)应该可以扩展，但是不能修改。它是软件设计中也是最重要的一种设计原则。
　　2.2，OCP的两个特征：
　　　　2.2.1> 对于扩展是开放的。
　　　　2.2.2> 对于修改是封闭的。

　　2.3，什么时候应用OCP原则呢？
　　　　在我们最初编写代码时，假设变化不会发生，当变化发生时，我们就创建抽象(比如抽象类，接口等等)来隔离以后发生的同类变化。
　　2.4，开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护，可扩展，可复用，灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
　　2.5，OCP的UML图：

class SubCompanyManager{
public List<SubEmployee> getAllEmployee(){
List<SubEmployee> list = new ArrayList<SubEmployee>();
for(int i=0; i<100; i++){
SubEmployee emp = new SubEmployee();
//为分公司人员按顺序分配一个ID
emp.setId("分公司"+i);
list.add(emp);
}
return list;
}
public void printEmployee(){
List<SubEmployee> list = this.getAllEmployee();
for(SubEmployee e:list){
System.out.println(e.getId());
}
}
}

class CompanyManager{
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<Employee>();
for(int i=0; i<30; i++){
Employee emp = new Employee();
//为总公司人员按顺序分配一个ID
emp.setId("总公司"+i);
list.add(emp);
}
return list;
}

public void printAllEmployee(SubCompanyManager sub){
sub.printEmployee();
List<Employee> list2 = this.getAllEmployee();
for(Employee e:list2){
System.out.println(e.getId());
}
}
}

View Code
修改后，为分公司增加了打印人员ID的方法，总公司直接调用来打印，从而避免了与分公司的员工发生耦合。

小结：

迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。