你不需要再向任何人解释 SOLID 了，这篇文章的5个插图就足够了

如果你熟悉面向对象编程，那么你一定听说过SOLID原则。

这五个软件开发原则是开发大规模软件时应遵循的指导方针，以便我们写的代码更容易扩展和维护。

网上有很多关于SOLID的优秀文章，但我很少看到带有图片的例子。对于像我这样的视觉学习者来说，这使得学习这些原则变得有些困难和枯燥。

因此，本文的主要目的是通过插图来更好地理解这些原则，并强调每个原则提出的目标。

S — 单一职责

一个类应该只有一个责任，即一个类应该有且仅有一个引起它变化的原因。如果一个类具有多项职责，则会增加出现错误的可能性，因为对其中一项职责进行更改可能会在您不知情的情况下影响其他职责。

这个原则的核心概念是将一个类限制在一个责任范围内，避免类过于庞大、复杂和难以维护。遵循单一职责原则有以下好处：

• 高内聚性：类的职责更加清晰明确，内部的相关功能和数据更加紧密相关，提高了类的内聚性。
• 易于理解和维护：类的职责更加集中，使得代码更加清晰易懂，易于理解和维护。
• 降低耦合度：不同的职责分别封装在不同的类中，减少了类之间的依赖关系，降低了耦合度，提高了代码的灵活性和可维护性。
• 便于重用和扩展：当需要修改或扩展功能时，只需要修改与该功能相关的类，而不会影响到其他类，提高了代码的可重用性和扩展性。

在实践中，遵循单一职责原则通常会导致类的数量增加，但这是值得的，因为它提高了代码的清晰度和可维护性，使得系统更容易扩展和维护。

O — 开闭

类应该对扩展开放，但对修改关闭，简单来说，就是应该尽量在不修改原有代码的情况下，通过扩展来实现新的功能需求。这样可以防止对现有功能的破坏，保证系统的稳定性和可靠性。

L —里氏替换

里氏替换原则指出：子类对象应该能够替换其父类对象而不影响程序的正确性，也就是说如果 S 是 T 的子类型，那么程序中类型 T 的对象可以被类型 S 的对象替换，程序的行为不应该受到影响，即程序应该继续按照预期工作。

图片显示父类提供咖啡（可以是任何类型的咖啡）。子类提供卡布奇诺（Cappuccino）是可以接受的，因为它是一种特定类型的咖啡，但提供水是不可接受的。

具体来说，里氏替换原则包含以下几个要点：

• 行为一致性：子类应该表现出与其父类相同的行为。这意味着子类应该实现父类中的所有方法，并且遵循相同的约束。
• 不破坏程序正确性：在使用子类对象替换父类对象时，程序的行为不应该受到影响，即程序应该继续按照预期工作。
• 约束松弛：子类可以对父类的行为进行扩展，但不能缩小父类的约束。换句话说，子类可以增加新的方法或功能，但不能改变已有方法的预期行为或限制条件。

该原则旨在强制一致性，以便父类或其子类可以以相同的方式使用而不会出现任何错误。

I —接口隔离

接口隔离原则指出客户端不应该依赖于它不需要的接口。简单来说，接口隔离原则要求将大接口拆分成多个小接口，以便客户端只需知道它们所需的方法，而不需要知道不必要的方法。

具体来说，接口隔离原则包含以下几个要点：

• 接口粒度合适：在保证接口的功能完整情况下接口应该尽量小，接口过大会导致客户端依赖不必要的方法，违反了接口隔离原则。

• 依赖倒置原则：依赖于抽象而不是具体实现，客户端应该依赖于接口而不是具体的类。这样可以减少客户端对具体实现的依赖，提高系统的灵活性。

• 接口细化：如果一个接口过大，可以将其拆分为多个小接口，每个小接口只包含相关的方法。这样可以降低接口的耦合度，提高系统的可维护性和可扩展性。

接口隔离原则的核心思想是将一个臃肿的接口分解为多个精细的接口，使得客户端只需依赖于需要的接口，从而降低了耦合度，提高了系统的灵活性、可维护性和可扩展性。

D —依赖倒置

依赖倒置原则的核心思想是高层模块不应该依赖于低层模块，二者都应该依赖于抽象；而且抽象不应该依赖于细节，细节应该依赖于抽象，这意味着系统的设计应该基于接口和抽象类，而不是具体的实现类。

接口隔离原则旨在通过引入接口来减少高级类对低级类的依赖，帮助我们设计出更加灵活、可维护和可扩展的软件系统。

更多高质量原创技术文章可扫码关注公众号：“非科班大厂码农”