设计模式的六大原则。简称：SOLID

设计模式的六大原则。简称：SOLID

迪米特法则（Law of Demeter）：如果两个类之间并不需要直接通信，那么就不应该让这两个类相互作用。又叫作最少知识原则
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
从迪米特法则的定义和特点可知，它强调以下两点：
1.从依赖者的角度来说，只依赖应该依赖的对象。
2.从被依赖者的角度说，只暴露应该暴露的方法。

一、单一职责原则 (Single Responsibility Principle, SRP)

单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
栗子：餐厅服务员负责把订单给厨师去做，而不是服务员又要订单又要炒菜。
好处：降低类复杂性降低，提高代码可读性，提高可维护性。

举例：防抖节流

二、开闭原则 (Open-Closed Principle, OCP)

含义：软件模块应该对扩展开放，对修改关闭。在程序需要进行新增功能的时候，不能去修改原有的代码，而是新增代码。
栗子：一开始做了普通计算器程序，突然添加新需求，要再做一个程序员计算器，这时不应该修改普通计算器内部，应该使用面向接口编程，组合实现扩展。
好处：为了使程序的扩展性好，易于维护和升级。

举例：vue expose defineExpose

三、里氏代换原则 (Liskov Substitution Principle, LSP)
含义：子类可以扩展父类的功能，但不能改变父类原有的功能。如果需要增加个性化，就应该对父类进行扩展，而不是重写。

栗子：机动车必须有轮胎和发动机，子类宝马和奔驰不应该改写没轮胎或者没发动机。父类有个抽象的车身类，子类宝马扩充，子类奔驰扩充。
好处：对实现抽象化的具体步骤的规范。

四、接口隔离原则 (Interface Segregation Principle, ISP)
类间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的几口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。说白了就是让客户端依赖的接口尽可能地小。
拆分一个大接口，成几个小接口
含义：
客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上

接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，或者拆分接口为多个。应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
栗子：电话接口只约束接电话和挂电话，不需要让依赖者知道还有通讯录。
好处：提高系统的灵活性和可维护性。

五、依赖倒转原则 (Dependence Inversion Principle, DIP)
含义：用接口interface。高层模块不应该依赖低层模块，二者都应该依赖其抽象。针对接口编程，而不是针对实现编程。
类A内有类B对象，称为类A依赖类B，但是不应该这样做，而是选择类A去依赖抽象。
栗子：以电脑为例,无论主板、CPU、内存、硬件都是在针对接口设计的，如果出现某个局部的配件坏了就只要替换对应的配件就行了。如果针对实现来设计，那么电脑显示屏坏了就需要把主机也一并换掉。
模板方法模式、工厂模式。

例如垃圾收集器不管垃圾是什么类型，要是垃圾就行。
好处：降低模块间的耦合。

第六、迪米特法则（Law of Demeter）：如果两个类之间并不需要直接通信，那么就不应该让这两个类相互作用。又叫作最少知道原则
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
从迪米特法则的定义和特点可知，它强调以下两点：
1.从依赖者的角度来说，只依赖应该依赖的对象。
2.从被依赖者的角度说，只暴露应该暴露的方法。
例子：外观模式facade，多个方法在外观方法中打包。

/**
 * @author 26530
 * 功能
 */
public interface Function 
{
     void start();
     void close();
}

public class CPU implements Function{

	@Override
	public void start() 
	{
		System.out.println("启动CPU");
	}

	@Override
	public void close() 
	{
		System.out.println("关闭CPU");
		
	}

}

public class Disk implements Function{

	@Override
	public void start() 
	{
		System.out.println("启动磁盘");
	}

	@Override
	public void close() 
	{
		System.out.println("关闭磁盘");
		
	}
}

public class Memory implements Function{

	@Override
	public void start() 
	{
		System.out.println("启动内存");
	}

	@Override
	public void close() 
	{
		System.out.println("关闭内存");
		
	}
}

public class Computer implements Function
{

	private CPU cpu;
	private Disk disk;
	private Memory memory;
	@Override
	public void start() 
	{
		this.cpu.start();
		this.disk.start();
		this.memory.start();
	}

	@Override
	public void close() 
	{
		this.cpu.close();
		this.disk.close();
		this.memory.close();
	}

	public Computer() 
	{
		this.cpu = new CPU();
		this.disk = new Disk();
		this.memory = new Memory();
	}
	
	

}

public class Test 
{
     public static void main(String[] args)
     {
    	 Computer computer = new Computer();
    	 computer.start();
    	 computer.close();
    	 /*
    	          启动CPU
			启动磁盘
			启动内存
			关闭CPU
			关闭磁盘
			关闭内存
    	  */
	 }
}

总述
没人写一款程序能完全遵守SOLID原则，甚至有些设计模式是违反SOLID原则。如何权衡就要看利是否大于弊。