如何用白话解释面向对象的SOLID原则？

面向对象的SOLID原则 简介 缩写 全称 中文 S The Single Responsibility Principle 单一责任原则 O The Open Closed Principle 开放封闭原则 L Liskov Substitution Principle 里氏替换原则 I The Interface Segregation Principle 接口分离原则 D The Dependency Inversion Principle 依赖倒置原则 单一职责原则 一个类只应承担一种责任。换句话说，让一个类只做一件事。如果需要承担更多的工作，那么分解这个类。 举例 订单和账单上都有流水号、业务时间等字段。如果只用一个类表达，赋予其双重职责，后果: 特有属性和共有属性相互掺杂，难以理解; 修改一个场景可能会影响另一个场景。 正确的做法是拆成两个独立的类。 开放封闭原则 实体应该对扩展是开放的，对修改是封闭的。即，可扩展(extension)，不可修改(modification)。 举例 一个商户接入了多个付款方式，支付宝和微信支付，如果将调用支付API的类写成： public class PayHandler { public Result<T> pay(Param param) { if(param.getType() == "ALIPAY") { // 支付宝付款调用 ... } else if(param.getType() == "WeChatPay") { // 微信支付付款调用 ... } } } 那么每次新加一种支付方式，或者修改原有的其中一种支付方式，都要修改PayHandler这个类，可能会影响现有代码。 比较好的做法是将不同的行为(支付方式)抽象，如下： public class PayHandler { private Map<String, PayProcessor> processors; public Result<T> pay(Param param) { PayProcessor payProcessor = processors.get(param.getType()); // 异常处理略 return payProcessor.handle(param); } } interface PayProcessor { Result<T> handle(Param param); } public class AlipayProcessor implements PayProcessor { ... } public class WeChatPayProcessor implements PayProcessor { ... } 这样，新增支付方式只需要新增类，如果使用的是spring等容器，在xml配置对应key-value关系即可；修改已有的支付方式只需要修改对应的类。最大化地避免了对已有实体的修改。 里式替换原则 一个对象在其出现的任何地方，都可以用子类实例做替换，并且不会导致程序的错误。换句话说，当子类可以在任意地方替换基类且软件功能不受影响时，这种继承关系的建模才是合理的。 举例 经典的例子: 正方形不是长方形的子类。原因是正方形多了一个属性“长 == 宽”。这时，对正方形类设置不同的长和宽，计算面积的结果是最后设置那项的平方，而不是长*宽，从而发生了与长方形不一致的行为。如果程序依赖了长方形的面积计算方式，并使用正方形替换了长方形，实际表现与预期不符。 扩展 不能用继承关系(is-a)，但可以用委派关系(has-a)表达。上例中，可以使用正方形类包装一个长方形类。或者，将正方形和长方形作进一步抽象，使用共有的抽象类。 逸闻 “里氏”指的是芭芭拉·利斯科夫（Barbara Liskov，1939年－），是美国第一个计算机科学女博士，图灵奖、冯诺依曼奖得主，参与设计并实现了OOP语言CLU，而CLU语言对现代主流语言C++/Java/Python/Ruby/C#都有深远影响。其项目中提炼出来的数据抽象思想，已成为软件工程中最重要的精髓之一。（来源: 互动百科） 接口分离原则 客户(client)不应被强迫依赖它不使用的方法。即，一个类实现的接口中，包含了它不需要的方法。将接口拆分成更小和更具体的接口，有助于解耦，从而更容易重构、更改。 举例 仍以商家接入移动支付API的场景举例，支付宝支持收费和退费；微信接口只支持收费。