面向对象五大基本原则理解（SOLID）_面向对象solid原则-CSDN博客

class Book {
	String name;
	String authorName;
	int year;
	int price;
	String isbn;

	public Book(String name, String authorName, int year, int price, String isbn) {
		this.name = name;
		this.authorName = authorName;
		this.year = year;
        this.price = price;
		this.isbn = isbn;
	}
}

还有一个类Invoice（发票），它有很多的功能，例如计算书本的总价、打印发票、保存到文件中等等。

public class Invoice {

	private Book book;
	private int quantity;
	private double discountRate;
	private double taxRate;
	private double total;

	public Invoice(Book book, int quantity, double discountRate, double taxRate) {
		this.book = book;
		this.quantity = quantity;
		this.discountRate = discountRate;
		this.taxRate = taxRate;
		this.total = this.calculateTotal();
	}

	public double calculateTotal() {
	        double price = ((book.price - book.price * discountRate) * this.quantity);

		double priceWithTaxes = price * (1 + taxRate);

		return priceWithTaxes;
	}

	public void printInvoice() {
            System.out.println(quantity + "x " + book.name + " " +          book.price + "$");
            System.out.println("Discount Rate: " + discountRate);
            System.out.println("Tax Rate: " + taxRate);
            System.out.println("Total: " + total);
	}

        public void saveToFile(String filename) {
	// Creates a file with given name and writes the invoice
	}

}

上面的代码因为功能实现的比较简单，代码看起来还不是很长。

试想一下，如果每个方法的逻辑更加复杂，在public方法的基础上可能还要再加上一些private方法。随着复杂程度的提升，“需求变更”带来的威胁将越来越大。

“小张啊，我觉得你的计算规则太落后了，我这有个新的计算规则，你来实现下”，“存到文件还不够，我还想存到数据库里”。。。。。。

每一次需求变更都迫使你重新阅读这个类的代码。尤其是多人合作的时候，更容易出错。

归根揭底都是这个类太“累”了，承受了不属于这个年纪应该承受的压力。

这个时候就需要给这个类“减负”了。

这个“减负”的过程，也叫做“解耦”。

编写InvoicePrinter类用于打印发票

public class InvoicePrinter {
    private Invoice invoice;

    public InvoicePrinter(Invoice invoice) {
        this.invoice = invoice;
    }

    public void print() {
        System.out.println(invoice.quantity + "x " + invoice.book.name + " " + invoice.book.price + " $");
        System.out.println("Discount Rate: " + invoice.discountRate);
        System.out.println("Tax Rate: " + invoice.taxRate);
        System.out.println("Total: " + invoice.total + " $");
    }
}

编写InvoicePersistence用于存储。

public class InvoicePersistence {
    Invoice invoice;

    public InvoicePersistence(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToFile(String filename) {
        // Creates a file with given name and writes the invoice
    }
}

类职责的单一化，也能带来其他的好处，例如每一个功能点都可以有多种实现策略，当需求变更时，只要切换策略即可。

开闭原则（The Open-Closed Principle）

类应该对拓展开放，对修改关闭

SRP原则可以让一个功能点的修改不影响到其他的功能点。

而开闭原则则有着更高一点要求，我们在新增方案时，可以复用之前的方案、可以拓展之前的方案，但是不能直接修改之前的方案。

通过拓展一个类的方式，来规避修改一个类可能带来的风险。

如上面的类InvoicePersistence：

假设需要新增一种基于数据库的存储方式，如果直接在InvoicePersistence上做补充

public class InvoicePersistence {
    Invoice invoice;

    public InvoicePersistence(Invoice invoice) {
        this.invoice = invoice;
    }

    public void saveToFile(String filename) {
        // Creates a file with given name and writes the invoice
    }

    public void saveToDatabase() {
        // Saves the invoice to database
    }
}

InvoicePersistence本身就是一个大的功能点——“存储”（save），但是这个功能点的实现方案有两种，所以我们可以先定义功能接口

interface InvoicePersistence {

    public void save(Invoice invoice);
}

再分配实现两种方案

public class DatabasePersistence implements InvoicePersistence {

    @Override
    public void save(Invoice invoice) {
        // Save to DB
    }
}

public class FilePersistence implements InvoicePersistence {

    @Override
    public void save(Invoice invoice) {
        // Save to file
    }
}

两种方案之间互相独立，互不影响。

调用方需要使用到发票存储功能时，只要持有InvoicePersistence类型的引用，即可借助Spring之类的对象管理工具快速完成策略的替换，调用方无需与具体的实现方案耦合。

说到底，这又是一种“解耦”，将实现方案与实现方案解耦、调用方（客户端）与具体服务解耦。

里氏替换原则（Liskov Substitution Principle）

子类（派生类）可以替换他们的基类

当我们定义一个子类时，通常是为了拓展基类的功能。“拓展”意味着保留原有的功能，在原有的功能基础上，加一些定制化的功能。但如果随意修改原有的功能，将会带来语义上的不明确，以及一些奇奇怪怪的bug。

以JDK中的List为例

List代表着一种特征，List种定义了很多的接口，用于维护这种特征。

所有List的实现类，都需要满足这种特征。不管是基于链表的LinkedList，还是基于数组的ArrayList，都是一种List。当客户端调用size()方法时，只能返回这个List的长度，而不是容量；调用get(int) 方法时，只能是获取指定下标的元素，至于获取方式可以定制化，数组的随机读取亦或者是链表的遍历读取都可以。

基类的方法（接口亦是），起到约束功能的作用，当子类覆盖（实现）父类方法时，可以采用不同的实现方式，但是总体方向不能变。

原文中有一个比较有意思的案例，虽说这个案例有些争议，但不影响我们学习这种思想。

在数学上，正方形是一种特殊的长方形。

定义一个类：Rectangle（长方形）

class Rectangle {
	protected int width, height;

	public Rectangle() {
	}

	public Rectangle(int width, int height) {
		this.width = width;
		this.height = height;
	}

	public int getWidth() {
		return width;
	}

	public void setWidth(int width) {
		this.width = width;
	}

	public int getHeight() {
		return height;
	}

	public void setHeight(int height) {
		this.height = height;
	}

	public int getArea() {
		return width * height;
	}
}

定义一个类正方形Square，继承自Rectangle。

class Square extends Rectangle {
	public Square() {}

	public Square(int size) {
		width = height = size;
	}

	@Override
	public void setWidth(int width) {
		super.setWidth(width);
		super.setHeight(width);
	}

	@Override
	public void setHeight(int height) {
		super.setHeight(height);
		super.setWidth(height);
	}
}

测试类

class Test {

   static void getAreaTest(Rectangle r) {
      int width = r.getWidth();
      r.setHeight(10);
      System.out.println("Expected area of " + (width * 10) + ", got " + r.getArea());
   }

   public static void main(String[] args) {
      Rectangle rc = new Rectangle(2, 3);
      getAreaTest(rc);

      Rectangle sq = new Square();
      sq.setWidth(5);
      getAreaTest(sq);
   }
}

Square由于本身的特征约束（正方形四条边相等），height与width必须相等。

但是这种约束不应该放在set方法中维持，对于客户端来说，Square就是一种Rectangle。用多态来描述就是 Rectangle sq = new Square()，那么Square类型的对象也可以作为getAreaTest(Rectangle r)的合法传参，这个时候就可能得到意料之外的结果。

更好的方式是Square和Rectangle定义成两个独立的类。在现实世界中比较合理的关系，直接抽象成代码时，可能就没那么合理了。

关于长方形和正方形的抽象问题，颇有争议，有兴趣的自行研究下。

里氏替换原则，注重的是子类与父类之间的兼容性。子类继承父类的方法（功能），可以换一种实现方式，但必须达到同样的目的。

接口隔离原则（Interface Segregation Principle）

客户端不应该依赖它不需要的接口

接口隔离原则很好理解，以停车场ParkingLot为例：

public interface ParkingLot {

	void parkCar();	// Decrease empty spot count by 1  开始停车
	void unparkCar(); // Increase empty spots by 1     结束停车
	void getCapacity();	// Returns car capacity        获取停车场的容量
	double calculateFee(Car car); // Returns the price based on number of hours 
	void doPayment(Car car);
}

class Car {

}

此接口在某种意义上讲，属于“胖接口”。如果现在需要实现一个免费的停车场只能这么做：

public class FreeParking implements ParkingLot {

	@Override
	public void parkCar() {
		
	}

	@Override
	public void unparkCar() {

	}

	@Override
	public void getCapacity() {

	}

	@Override
	public double calculateFee(Car car) {
		return 0;
	}

	@Override
	public void doPayment(Car car) {
		throw new Exception("Parking lot is free");
	}
}

费用计算固定返回0、支付接口直接抛异常，这显然是一种不优雅的做法。究其根本，还是抽象的不够彻底，并非所有的停车场都是付费的，对于“付费”这一特征可以单独抽象出来。

搬个图