【设计模式】第2节：七大设计原则

原则"/>

【设计模式】第2节：七大设计原则

一、七大设计原则

七大原则提出的目的是降低对象之间的耦合度，提高程序的可复用性、可扩展性和可维护性。

1.单一职责原则

Single Responsibility Principle，SRP原则：一个类只负责一个功能领域中的相应职责。或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。单一职责原则是实现高内聚、低耦合的指导方针。

• 降低类的负责度，一个类只负责一项职责。
• 提高类的可读性，可维护性。
• 降低变更带来的风险。

2. 开放封闭原则

Open Closed Principle，OCP原则：需求改变时，在不改变软件实体源代码（类、接口、方法等）的前提下，通过扩展功能，使其满足新的需求。功能是开放的（功能提供方），代码修改是封闭的（功能使用方）。

• 用抽象构建框架，用实现扩展细节
• 参数类型、引用对象尽量使用接口或抽象类
• 抽象层尽量保持稳定：接口和抽象类只负责定义方法，但不负责具体实现

3. 里式替换原则

Liskov Substitution Principle，LSP原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。里氏代换原则表明，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立。该原则实际是在使用继承关系时的指导原则，遵循了该原则，那么采用继承时就不容易出错。

• 子类必须完全实现父类的抽象方法，但不能覆盖父类的非抽象方法
• 子类可以实现自己特有的方法
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格‘
• 子类的实例可以替代任何父类的实例，但反之不成立

4.接口隔离原则

Interface Segragation Principle，ISP原则：客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。接口尽量细分，不要在一个接口中放很多方法。

接口分离原则和单一职责原则的关系：单一职责原则是为了高内聚，接口分离原则是为了低耦合。

5.依赖倒置原则

Dependence Inversion Principle，DIP原则：

• 高层模块不应该依赖底层模块，二者都应该依赖其抽象（接口）。
• 抽象不应该依赖细节，细节应该依赖抽象。

依赖倒置的本质是通过抽象（接口或抽象类）是各个类或模块的实现彼此独立，互不影响，实现模块间的低耦合。相对于细节的多变性，抽象的东西要稳定的多。应用依赖倒置的设计模式：工厂方法。

class BMW {public void rentBMW(String model) {System.out.println("BMW rented" + model);}
}class Mercedes {public void rentMercedes(String model) {System.out.println("Mercedes rented" + model);}
}public class CarRentalAgency {public static void main(String[] args) {CarRentalAgency agency = new CarRentalAgency();agency.rentCar("BMW", "X5");agency.rentCar("Mercedes", "GLE");}public void rentCar(String brand, String model) {if (brand == "BMW") {new BMW().rentBMW(model);      } else if (brand == "Mercedes") {new Mercedes().rentMercedes(model);      }}
}

interface CarManufactory {public void rent(String model);
}class BMW implements CarManufactory {public void rent(String model) {System.out.println("BMW rented" + model);}
}class Mercedes implements CarManufactory {public void rent(String model) {System.out.println("Mercedes rented" + model);}
}class Honda implements CarManufactory {public void rent(String model) {System.out.println("Honda rented" + model);}
}public class CarRentalAgency {public static void main(String[] args) {CarRentalAgency agency = new CarRentalAgency();agency.RentCar(new BMW(), "X5");agency.RentCar(new Mercedes(), "GLE");agency.RentCar(new Honda(), "Accord");}pubcic void rentCar(CarManufactory cm, String mode) {cm.rent(mode);}
}

一个优秀的面向对象的程序设计，核心原则之一就是将变化隔离/封装，使得变化的部分发生变化时，对其他部分无影响。为了实现这个目的，需要使用面向接口编程，使用后，客户类不再直接依赖服务类，而是依赖一个抽象的接口，这样，客户类就不能在内部直接实例化服务类。但是客户类在运行的过程中，又需要具体的服务类来提供服务，因为接口是不能实例化的，就产生了一个矛盾：客户类不允许实例化服务类，但是客户类又需要服务类的服务。为了解决这个矛盾，设计了一种解决方案：客户类定义一个注入点，用于服务类的注入，而客户类负责根据情况，实例化服务类，注入到客户类中，从而解决了这个矛盾，该过程即依赖注入。

依赖注入的三种方式：

• 接口注入：在接口/类中，将要注入的服务对象，以参数的形式直接注入
• 构造方法注入：通过构造函数来传入具体类的对象
• set方法注入：通过Setter方法来传入具体类的对象

开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，它们相互补充，相辅相成，目标一致，只是分析问题时所站角度不同而已。以上五个原则根据其首字母，又被称为SOLID原则。

6.合成复用原则

尽量使用对象聚合/ 组合，而不是继承来达到复用的目的。

继承复用：

• 优点：简单，容易实现
• 缺点：破坏了封装性，耦合度高，限制灵活性

合成复用：

• 优点：维持封装性，降低耦合度，灵活性高
• 缺点：有较多的对象需要管理

7.迪米特原则

The Least Knowledge Principe,/Demeter Principle：它要求一个对象应该对其他对象有最少的了解（最少知识原则），降低类之间的耦合。迪米特原则实际上就是一个类在创建方法和属性时要遵守的法则。

迪米特法则还有一种定义形式：不要和“陌生人”说话，只与你的直接朋友通信等。在迪米特法则中，对于一个对象，其“朋友”包括以下几类:

• 当前对象本身（this）；
• 以参数形式传入到当前对象方法中的对象；
• 当前对象的成员对象；
• 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
• 当前对象所创建的对象。

遵循迪米特原则的设计模式：

• 门面模式
• 中介模式

class Card {public int balance = 10;
}class Customer {private Card card = new Card();public Card getCard() {return this.card;}
}public class SurfShop {public static void main(String[] args) {SurfShop surfShop = new SurfShop();Customer customer = new Customer();surfShop.chargeCustomer(customer, 10);System.out.println("Done");}public void chargeCustomer(Customer c, float fee) {c.getCard().balance -= fee;}
}

class Card {public int balance = 10;public void deduct(flaot fee) {this.balance -= fee;}
}class Customer {private Card card = new Card();public void pay(float fee) {this.card.deduct(fee);}
}public class SurfShop {public static void main(String[] args) {SurfShop surfShop = new SurfShop();Customer customer = new Customer();surfShop.chargeCustomer(customer, 10);System.out.println("Done");}public void chargeCustomer(Customer c, float fee) {c.pay(fee);}
}