一、七大设计原则
七大原则提出的目的是降低对象之间的耦合度，提高程序的可复用性、可扩展性和可维护性。
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);
}
}
