1. 单一职责原则（Single Responsibility Principle, SRP）
每个类应该只有一个职责，且该职责应该完全封装在类中。
解释：
一个类应该只有一个引起它变化的原因。换句话说，类只应该负责处理一种类型的功能或任务，避免类承担过多的责任。
为什么重要：如果一个类有多个职责，当其中一个职责变化时，可能会影响到其他职责，导致代码变得难以维护和扩展。保持类的职责单一，可以降低系统的耦合度，增加可读性。
示例：
不应该在同一个类中同时处理用户界面逻辑和数据存储。应将这两种责任分离成两个独立的类，一个处理 UI，另一个处理数据存储。
2. 开放封闭原则（Open/Closed Principle, OCP）
软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。
解释：
该原则意味着当系统需要添加新功能时，应该通过扩展现有的代码（如继承、接口实现等）来完成，而不是修改已有的代码。
为什么重要：如果每次添加新功能都需要修改现有代码，就可能引入不必要的错误，降低代码的可维护性。通过扩展现有功能，可以保证现有系统的稳定性。
示例：
如果需要增加一个新的支付方式（如 Apple Pay），我们可以通过添加新的支付类来扩展，而不是修改已有的支付类。这样我们保持了代码的可扩展性。
3. 里氏替换原则（Liskov Substitution Principle, LSP）
子类对象应该能够替换父类对象并正常工作。
解释：
里氏替换原则要求子类应当完全遵循父类的行为，并且没有改变父类的行为。换句话说，子类可以替代父类，但它必须能够正常工作，并且不会破坏父类的功能。
为什么重要：这个原则确保了继承层次结构的一致性，确保子类能够在不破坏父类行为的情况下实现或扩展父类的功能。
示例：
假设有一个 Bird 类和它的子类 Penguin（企鹅）。Bird 类中有一个 fly() 方法，如果 Penguin 继承自 Bird，但是企鹅不具备飞行能力，那么 Penguin 不能直接继承 Bird 类，或者需要重写 fly() 方法使其符合企鹅的特性。这个违背了里氏替换原则，因此应该重构类设计，例如让 Bird 类只定义可以飞行的鸟类。
4. 接口隔离原则（Interface Segregation Principle, ISP）
不应强迫客户端依赖它们不需要的接口。
解释：
该原则认为，接口应该尽量小而专注，避免定义过于庞大的接口，导致实现类必须实现它们不需要的功能。
为什么重要：当接口过于庞大时，客户端可能会因为需要实现一个接口中不相关的方法而增加不必要的代码量。通过拆分接口，可以使得客户端只实现它们需要的部分，避免了代码臃肿。
示例：
假设有一个 Worker 接口，定义了很多不同的方法，如 work()、eat()、sleep() 等。如果有一个类 Robot 实现了 Worker 接口，但并不需要 eat() 和 sleep() 方法，那么它就不应该实现这些方法。相反，可以将接口拆分成多个更小的接口，比如 Workable、Eatable 等，Robot 只实现它需要的 Workable 接口。
5. 依赖倒转原则（Dependency Inversion Principle, DIP）
高层模块不应该依赖低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。
解释：
该原则要求高层模块（如应用程序的业务逻辑）和低层模块（如数据访问、外部服务）都应该依赖于抽象（如接口或抽象类），而不是直接依赖具体的实现。
为什么重要：通过依赖于抽象，我们能够减少高层模块对低层模块的直接依赖，从而增强系统的灵活性和可扩展性。这也有助于解耦系统的不同部分，使得代码更加易于维护。
示例：
假设有一个 UserService 类，它直接依赖于具体的数据库实现（如 MySQLDatabase）。如果我们将 UserService 修改为依赖于 Database 接口，而不是 MySQLDatabase，那么就可以通过提供不同的数据库实现来切换数据库系统，而无需修改 UserService 类。
