面向对象设计中的五大核心原则（SOLID原则）
面向对象设计中的五大核心原则SOLID原则分别对应SRP单一职责原则一个类应仅有一个引起它变化的原因即只承担一种职责提高内聚、降低耦合。OCP开闭原则软件实体类、模块、函数等应对扩展开放、对修改关闭可通过抽象、多态、策略模式等实现。LSP里氏替换原则子类型必须能够替换其父类型而不影响程序正确性要求子类不加强前置条件、不削弱后置条件、不变量保持。ISP接口隔离原则不应强迫客户端依赖于它不需要的接口应将庞大接口拆分为多个小而专一的接口。DIP依赖倒置原则高层模块不应依赖低层模块二者都应依赖抽象抽象不应依赖细节细节应依赖抽象是实现松耦合和可测试性的基石。这些原则共同支撑可维护、可扩展、可复用的高质量软件架构。识别并重构违反**单一职责原则SRP**的“上帝类”God Class是提升代码可维护性与可测试性的关键实践。以下是系统化的方法✅一、识别“上帝类”的典型信号类名宽泛模糊如Manager、Helper、Utils、Service无前缀/后缀限定文件行数 500 行方法数量 20 个或单个方法 100 行方法职责混杂同时处理数据校验、数据库操作、HTTP调用、日志记录、缓存更新、业务规则计算等成员变量过多且语义分散如既有userDao、emailSender、redisTemplate、configLoader单元测试用例覆盖多个不相关场景且测试需大量 mock 外部依赖修改一个功能常导致 unrelated 测试失败高耦合副作用。✅二、重构策略渐进式、安全、可验证职责分析用动词名词提炼每个方法的核心意图如validateOrder()、sendSms()、calculateDiscount()聚类相似职责提取类Extract Class将一组高内聚方法 相关字段 → 提取为新类如OrderValidator、DiscountCalculator原类保留协调逻辑Facade 或 Orchestrator通过组合而非继承复用新类引入领域分层按 DDD 思维划分职责边界——ApplicationService用例编排DomainService跨实体业务规则InfrastructureService发送邮件、调用第三方自动化保障重构前确保 100% 覆盖关键路径的单元测试使用 IDE 重构工具如 IntelliJ 的Extract Class/Extract Method保证引用一致性配合 SonarQube 检查Complexity、Class Fan-out、Cognitive Complexity等指标预警。✅三、示例简写Java// ❌ 违反SRP的OrderProcessor承担校验、持久化、通知、风控publicclassOrderProcessor{publicvoidprocess(Orderorder){/* 全部逻辑塞在这里 */}}// ✅ 重构后publicclassOrderService{// 协调者仅编排privatefinalOrderValidatorvalidator;privatefinalOrderRepositoryrepo;privatefinalNotificationServicenotifier;privatefinalRiskCheckerriskChecker;publicvoidprocess(Orderorder){validator.validate(order);riskChecker.check(order);repo.save(order);notifier.sendConfirmation(order);}}关键重构不是一次性大手术而是以小步提交、持续验证、测试护航的演进过程。
