里氏替换原则
我认为，里氏替换原则更多是体现在了父子类继承方面，强调的是子类在继承了父类对象的时候不应该破坏这个父类对象的设计初衷。
举个例子来说：
我们定义了一个提款的服务：
/** * @Author linhao * @Date created in 11:21 上午 2021/9/4 */ public interface DrawMoneyService { /** * 提款函数 * * @param drawMoneyInputParam */ void drawMoney(DrawMoneyInputParam drawMoneyInputParam); } 复制代码
对应的是一个抽象实现父类：
/** * @Author linhao * @Date created in 11:25 上午 2021/9/4 */ public abstract class AbstractDrawMoneyServiceImpl implements DrawMoneyService{ /** * 设计初衷，需要对提现金额进行参数校验 * * @param drawMoneyInputParam */ @Override public abstract void drawMoney(DrawMoneyInputParam drawMoneyInputParam); } 复制代码
正常的子类继承对应父类都应该是对入参进行一个校验判断，如果金额数值小于0，自然就不允许提现了。
/** * @Author linhao * @Date created in 11:22 上午 2021/9/4 */ public class AppDrawMoneyServiceImpl extends AbstractDrawMoneyServiceImpl{ @Override public void drawMoney(DrawMoneyInputParam drawMoneyInputParam) { if(drawMoneyInputParam.getMoney()>0){ //执行提款程序 } System.out.println("app提款业务"); } } 复制代码
但是如果某个实现的子类当中违背了这一设计原则，例如下边这种：
public class GZHDrawMoneyServiceImpl implements DrawMoneyService { @Override public void drawMoney(DrawMoneyInputParam drawMoneyInputParam) { if(drawMoneyInputParam.getMoney()<0){ //执行提款程序 } System.out.println("公众号提款业务"); } } 复制代码
那么这种情况下，子类的实现就违背了最初父类设计的初衷，此时就违背了里氏替换原则的思想。此时就容易给阅读代码的人感觉，不同的子类虽然都继承了同一个父类，但是在转账的参数校验逻辑上完全是东一套，西一套，没有特定的规矩，逻辑比较乱。
所以较好的做法是在父类中就将需要满足的基本逻辑定义好，保证子类在进行扩展的时候不会轻易造成修改。
另外说说多态和里氏替换原则两个名词：
从案例代码来看，你会发现似乎 多态 和 里氏替换 长得很相似。但是我个人认为这是两个不同领域的东西，前者是代码特有的属性，后者则是一种设计思想，正因为类有了多态的这种特性，人们才会重视在代码设计过程中需要遵守里氏替换原则。这一项原则在设计的过程中保证了代码设计的正确性，它更像是一种思路在指导着开发者如何设计出更加好维护和理解的程序。
接口隔离原则
关于接口隔离原则这部分，我们可以通过一个具体的实战案例来学习。
在和第三方服务进行对接的时候，通常我们需要接入一些密钥之类的相关信息，例如和支付宝的支付接口对接，和微信支付接口做对接，和银联支付做对接等等。
那么我们可以将这些不同场景下关于支付相关的信息的储存放在一个Config相关的对象中，如下所示：
/** * 基本的支付配置接口 * * @Author linhao * @Date created in 9:59 上午 2021/9/5 */ public interface BasePayConfig { } 复制代码
然后对每类支付配置都有对应的一个实现方式：
public class BankPayConfig implements BasePayConfig{ private String secretKey; private String appId; private String randomNumber; //getter和setter省略 } public class AliPayConfig implements BasePayConfig{ private String secretKey; private String appId; private String randomNumber; } public class WXPayConfig implements BasePayConfig{ private String secretKey; private String appId; private String randomNumber; } 复制代码
然后呢，实际场景中我们需要将这些配置信息给展示到一个后台管理系统的某个模块当中，所以后续我便在已有的BasePayConfig接口中定义了一个专门展示支付配置的函数：
public interface BasePayConfig { /** * 展示配置 */ Map<String,Object> showConfig(); } 复制代码
展示配置之后，需要在各个子类中去对不同的信息进行组装，最后返回一个Map的格式给到调用方。
但是随着业务的变动，某天需要对微信支付的配置信息实现可以替换更新的功能，但是额外的支付宝支付，银联支付不允许对外暴露这一权限。那么此时就需要对代码进行调整了。
调整思路一：
直接在BasePayConfig接口中进行扩展,代码案例如下：
public interface BasePayConfig { /** * 展示配置 */ Map<String,Object> showConfig(int code); /** * 更新配置信息 * * @return */ Map<String,Object> updateConfig(); } 复制代码
然后各个子类依旧是实现这些接口，并且即使不需要实现更新功能的支付宝配置类，银联配置类都必须强制实现。从这样的设计角度来思考就会发现，对于代码实现方面不是太友好，接口内部定义的函数粒度还可以再分细一些。
调整思路二：
将读取配置和更新配置分成两个接口，需要实现更新配置功能的类才需要去实现该接口。代码如下所示：
支付配置展示
/** * @Author linhao * @Date created in 10:19 上午 2021/9/5 */ public interface BasePayConfigViewer { /** * 展示配置 */ Map<String,Object> showConfig(int code); } 复制代码
支付配置更新
public interface BasePayConfigUpdater { /** * 更新配置信息 * * @return */ Map<String,Object> updateConfig(); } 复制代码
这样的设计能够保证，不同的接口专门负责不同的领域，只有当实现类确实需要使用该功能的时候才去实现该接口。写到这里的时候，你可以不妨再回过头去理解下我在文章上半部分中提及的接口隔离原则，相信你会有新的体会。
或许你也会有所疑惑，接口隔离原则好像和单一责任原则有些类似呀，都是各自专一地负责自己所管理的部分。但是我个人认为，接口隔离原则关注的是接口，而单一责任原则关注的目标可以是对象，接口，类，所涉及的领域更加广阔一些。
依赖反转原则
在介绍依赖反转原则之前，我们先来理解一个相似的名词，控制反转。
单纯的从Java程序来进行理解：
例如我们定义个BeanObject对象：
public interface BeanObject { void run(); } 复制代码
然后再定义相关的实现类，如消息发送：
public class MessageNotify implements BeanObject{ @Override public void run() { System.out.println("消息发送"); } } 复制代码
最后是一个Context上下文环境：
public class BeanContext { private static List<BeanObject> beanObjectList = new ArrayList<>(); static { beanObjectList.add(new MessageNotify()); } public static void main(String[] args) { beanObjectList.get(0).run(); } } 复制代码
从代码来看，可以发现对于MessageNotify的调用均是通过一个BeanContext组件调用来实现的，而并不是直接通过new MessageNotify的方式去显示调用。通过封装一个基础骨架容器BeanContext来管控每个BeanObject的run方法执行，这样就将该函数的调用权转交给了BeanContext对象管理。
控制反转
现在我们再来理解 控制反转 这个名词，“控制”主要是指对程序执行流程的控制，例如bean的调用方式。“反转”则是指程序调用权限的转变，例如从bean的调用方转变为了基础容器。
依赖注入
再来聊下依赖注入这个名词。
依赖注入强调的是将依赖属性不要通过显式的new方式来创建注入，而是将其交给了基础框架去管理。这方面的代表框架除了我们熟悉的Spring之外，其实还有很多，例如Pico Contanier等。
最后再来品味下官方对于依赖反转的介绍：
High-level modules shouldn’t depend on low-level modules. Both
modules should depend on abstractions. In addition, abstractions
shouldn’t depend on details. Details depend on abstractions.
高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。
依赖反转原则也叫作依赖倒置原则。这条原则跟控制反转有点类似，主要用来指导框架层面的设计。高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。
最后，希望这篇文章能够对你有所启发。
