摘要：定义：一个软件模块应该只有一个引起它变化的原因。也就是说，一个类应该只负责一项职责，而不应该承担过多的职责。如果一个类承担了过多的职责，那么当其中一个职责发生变化时，可能会影响到其他职责，从而导致类的复杂性增加，难以维护和扩展。

软件架构设计的五大核心原则在构建高质量、可维护且灵活的软件系统中起着关键作用。以下详细介绍这五大核心原则：

1. 单一职责原则（Single Responsibility Principle，SRP）

定义：一个软件模块应该只有一个引起它变化的原因。也就是说，一个类应该只负责一项职责，而不应该承担过多的职责。如果一个类承担了过多的职责，那么当其中一个职责发生变化时，可能会影响到其他职责，从而导致类的复杂性增加，难以维护和扩展。

示例：在一个简单的电商系统中，假设存在一个UserService类，它既负责用户注册、登录功能，又负责订单处理功能。当用户注册流程发生变化时，可能会不小心影响到订单处理的逻辑。按照单一职责原则，应该将用户相关的操作（注册、登录等）放在一个专门的UserService类中，而订单处理操作放在另一个OrderService类中。这样，每个类都只负责单一的职责，当某个功能需求发生变化时，只需要修改对应的类，不会对其他类产生不必要的影响。

2. 开放封闭原则（Open - Closed Principle，OCP）

定义：软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。这意味着在设计软件时，应该使软件实体在不修改现有代码的情况下，能够通过扩展来满足新的功能需求。通过抽象和多态等机制，将可变的部分封装起来，当有新的需求时，通过创建新的类或模块来实现扩展，而不是直接修改原有的代码。

示例：假设有一个图形绘制系统，已经实现了绘制圆形和矩形的功能。现在需要添加绘制三角形的功能。如果遵循开放封闭原则，在设计时会定义一个抽象的Shape类，包含一个抽象的draw方法。圆形、矩形类继承自Shape类并实现draw方法。当需要添加三角形功能时，只需要创建一个新的Triangle类继承自Shape类并实现draw方法，而不需要修改原有的圆形和矩形绘制代码。

3. 里氏替换原则（Liskov Substitution Principle，LSP）

定义：所有引用基类（父类）的地方必须能透明地使用其子类的对象。也就是说，子类对象必须能够替换掉它们的父类对象，而程序的行为不会发生任何异常或错误。这要求子类必须遵循父类的契约，实现父类定义的方法，并且不能削弱父类方法的前置条件，也不能强化父类方法的后置条件。

示例：假设有一个Rectangle类，有width（宽度）和height（高度）属性，以及计算面积的area方法。现在有一个Square类继承自Rectangle类。由于正方形是特殊的矩形，Square类应该能够替换Rectangle类在程序中的使用。但是，如果Square类在实现area方法时，没有遵循Rectangle类的契约，例如强制将width和height设置为相等，那么在使用Square类替换Rectangle类时，可能会导致程序出现错误。正确的做法是，Square类在继承Rectangle类的基础上，合理实现相关方法，以保证里氏替换原则的成立。

4. 接口隔离原则（Interface Segregation Principle，ISP）

定义：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。也就是说，应该将大的接口拆分成多个小的接口，让客户端只依赖它实际需要的接口，避免客户端被迫实现一些不需要的方法。

示例：假设有一个Worker接口，包含work（工作）、eat（吃饭）、sleep（睡觉）方法。现在有一个Programmer类和一个Robot类都需要实现Worker接口。然而，Robot类并不需要eat和sleep方法，但由于实现Worker接口，不得不实现这些方法，这就违背了接口隔离原则。正确的做法是将Worker接口拆分成更小的接口，如Workable接口（包含work方法）、Living接口（包含eat和sleep方法）。Programmer类可以实现Workable和Living接口，而Robot类只需要实现Workable接口。

5. 依赖倒置原则（Dependency Inversion Principle，DIP）

定义：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。在软件设计中，应该尽量依赖抽象类或接口，而不是具体的实现类。这样可以降低模块之间的耦合度，提高系统的灵活性和可维护性。

示例：在一个邮件发送系统中，有一个EmailSender类负责发送邮件，还有一个User类需要使用EmailSender类发送邮件。如果User类直接依赖EmailSender类，那么当邮件发送方式发生变化时，User类也需要进行修改。按照依赖倒置原则，应该定义一个抽象的MailSender接口，EmailSender类实现该接口。User类依赖MailSender接口，而不是具体的EmailSender类。这样，当需要更换邮件发送方式（例如从电子邮件改为短信发送）时，只需要创建一个实现MailSender接口的新类（如SmsSender类），而User类不需要进行修改。

来源：娱乐花猫