SOLID：C#中的单一职责原则（SRP）
原文英文，约800词，阅读约需3分钟。
📝
内容提要
单一职责原则（SRP）要求类只承担一个责任，以提升代码的可读性、可测试性和可维护性。违反SRP会导致紧耦合和灵活性降低。通过将类拆分为多个单一职责的类，可以改善设计，使软件更易于调试和扩展。遵循SRP有助于开发更清晰、可维护的代码。
🔎
延伸解读
单一职责原则的实际应用
在实际开发中，遵循单一职责原则（SRP）可以显著提高代码的可维护性和可读性。通过将复杂的类拆分为多个小类，开发者可以更容易地定位和修复问题，尤其是在大型项目中，代码的清晰性尤为重要。
SRP违反的后果
违反单一职责原则可能导致代码的紧耦合，使得一个类的修改影响到多个功能，增加了测试的复杂性和风险。例如，发票类同时处理生成、保存和发送邮件，任何一个功能的变化都可能导致其他功能出现问题。
何时考虑应用SRP
在设计类时，如果发现类的责任逐渐增多或开始处理独立变化的任务，就应考虑应用单一职责原则。及时重构代码可以避免未来的维护困难，确保代码的灵活性和可扩展性。
❓
Q&A
什么是单一职责原则（SRP）？
单一职责原则（SRP）要求类只承担一个责任，以提升代码的可读性、可测试性和可维护性。
违反SRP会导致什么后果？
违反SRP会导致紧耦合、灵活性降低和测试难度增加。
如何通过SRP改善代码设计？
通过将类拆分为多个单一职责的类，可以改善设计，使软件更易于调试和扩展。
能否举例说明SRP的违反？
例如，Invoice类同时处理生成发票、保存到数据库和发送邮件三个不同的责任，违反了SRP。
如何重构代码以遵循SRP？
可以将Invoice类拆分为InvoiceGenerator、InvoiceRepository和InvoiceEmailSender三个类，每个类只处理一个责任。
在什么情况下应该考虑应用SRP？
当类的责任开始增长或处理独立变化的责任时，应考虑应用SRP。
🏷️
