SOLID原则基本上可以帮助我们使我们的代码能够容忍变化，并且易于理解。它还可以帮助我们减少依赖性，这样我们就可以改变代码的一个区域而不影响到其他区域。
该原则是以下五个原则的首字母缩写。
- S : 单一责任原则
- O : 开放封闭原则
- L : Liskov替代原则
- I : 接口隔离原则
- D: 依赖性反转原则
单一责任原则：
这个原则说的是，一个模块只应该由一组行为者来改变。因此，在我们举例之前，让我们也了解一下谁是行动者。
行为者是那些将与应用程序互动的个人或系统。
让我们试着通过一个例子来更好地理解它。
那么，假设我们有一个现有的类，它实现了某种功能，如折扣计算，现在，让我们假设这个功能只被其中一个角色使用，这个角色可能是销售顾问。
现在，如果我们对原先用于销售顾问的同一个类进行修改。我们最终可能会增加对其他角色（即销售顾问）没有用处的功能。因此，原则是，与其改变共同的顶点类（包含经理和销售顾问的共同功能），我们可以为经理创建一个不同的类，它可以扩展共同的类，这样就可以拥有共同的功能以及他所需要的新功能，这样我们就可以确保对每个角色我们只改变一个类。
开放封闭原则：
这个原则说的是，Salesforce的实体应该是开放的，可以进行扩展，但对于修改来说是封闭的。
开放的实体可以是你的类、模块和函数。
现在，让我们试着通过一个例子来更好地理解它。
那么，让我们以上面的一个现有例子为例，假设我们有一个折扣计算组件，为Salesforce中的一个对象的最终用户计算折扣，现在你的用户来找你，说他们需要在其他一些对象上使用同样的组件。此外，他们还想要一个新的功能，即在计算折扣的同时，该组件还可以计算新对象的税金。现在，如果我们有一个不够灵活的代码，我们可以扩展现有类的能力，如果我们必须改变现有的折扣计算代码，使其现在包括税收计算逻辑，并可以扩展到其他对象，那么我们的代码就没有遵守这个原则，因为我们在修改现有的方法，而不是扩展它们。
因此，如果我们想在其他对象中使用同样的功能，并且不想修改现有的功能来扩展到其他对象，我们可以做的是利用接口（有折扣计算方法），让我们的新组件实现它。
Liskov替代原则：
这个原则简单地说就是一个超类的所有子类都应该能够实现所有的方法而不会发生错误。
让我们举一个简单的例子，我从视频系列中学到的。比方说，我们有一个动物超类，它有一个叫做 "咆哮 "的方法。现在我们有了我们的子类，例如狗和熊扩展了超类Animal。现在我们知道狗不会吼叫，但熊会，所以我们必须抛出一个狗不能吼叫的异常。所以，在这里你有一个子类（狗）实际上不能使用超类的一个方法，那么我们就违反了这个原则。
所以，我们需要确保我们的子类能够实现超类的所有方法，这样才不会违反原则。