一、SOLID 原则

单一职责原则

• Single Responsibility Principle，SRP
  一个类/模块仅负责一项明确职责，避免功能混杂。
• Separation of Concerns，SoC
  注点分离原则，把一个复杂的系统分成多个部分，每个部分只关注一件事。

开闭原则

• Open Closed Principle，OCP
  对扩展开放（可新增功能），对修改关闭（不改动现有代码）。

里式替换原则

• Liskov Substitution Principle，LSP
  子类必须能完全替代父类，且不破坏原有业务逻辑。

接口隔离原则

• Interface Segregation Principle，ISP
  客户端不应依赖它不需要的接口，拆分臃肿接口为专用小接口。

依赖反转原则

• Dependency Inversion Principle，DIP
  高层模块不依赖低层模块，二者均依赖抽象；抽象不依赖细节，细节依赖抽象。
• 依赖注入Dependency Injection
  通过外部传入依赖对象（而非内部创建），解耦组件与依赖。
• 控制反转Inversion Of Control
  将对象创建、流程控制的主动权交给框架，而非硬编码在业务代码中。

二、KISS原则

Keep It Simple and Straightforward

设计力求简单直接，复杂逻辑会增加维护成本与出错风险。

奥卡姆剃刀原理（Occam’s Razor）

当多个方案都能达成同一目标时，选择假设最少、最简单的那一个——”如无必要，勿增实体”（Entities should not be multiplied unnecessarily）。

三、YAGNI原则

You Ain’t Gonna Need It

不提前开发当前不需要的功能，避免过度工程。

过早优化是万恶之源

premature optimization is the root of all evil.

Rule of Three

同一段代码第三次出现时才重构复用，避免过度设计。

四、迪米特法则

Law of Demeter，LOD

对象仅与直接关联的对象交互，不依赖间接依赖的内部细节。——“只和直接朋友说话，不和陌生人说话”。

高内聚、低耦合

模块内部逻辑紧密相关（高内聚），模块间依赖尽可能少（低耦合）。

最小知识原则，The Least Knowledge Principle

对象应最小化对其他对象的了解，仅知晓必要的接口信息。

组合优先于继承原则，Composition Over Inheritance

设计中尽量使用组合而不是通过类继承来复用功能

五、最低入侵原则

Spring对比EJB

Spring无需实现特定接口或继承框架类（低入侵），EJB则强依赖框架规范（高入侵）。

六、DRY 原则

Don’t Repeat Yourself

避免重复代码与逻辑，通过抽象统一维护相同知识。

复用代码，Code Reusability

通过封装通用逻辑（函数/类/模块），减少重复编写。

不要重复造轮子

如果没有不得不做的理由，千万不要重复造轮子。

七、面向对象

封装、抽象、继承、多态

隐藏内部实现细节，仅通过公开接口与外界交互。

八、高级抽象

Linux中一切皆文件

将设备、进程等系统资源统一抽象为文件，用同一套API访问。

九、分层及模块化

按职责拆分系统为独立层/模块，降低耦合，提升可维护性。

十、为扩展而设计

预留扩展接口，确保新增功能时无需大幅修改现有代码。

十一、波斯特定律（鲁棒性原则）：发送时保守，接收时宽容。

对外提供接口时，自身输出的参数严格遵循格式规范；对接上游数据时，对合理的格式差异做兼容处理，提升系统整体容错性。

十二、最小惊奇原则

The Least Surprise Principle

代码行为应符合开发者直觉，避免反常识的设计。

十三、为维护者写代码

为维护者写代码、注释和文档

十四、拥抱变化

欢迎需求变更，即使在开发后期。敏捷过程利用变更为客户带来竞争优势。——《敏捷宣言》

十五、不要让用户思考

Don’t make me think!

十六、不要给客户行为做过多假设

你永远不知道用户怎么使用你的软件

十七、及时处理代码的坏味道（破窗效应）

当代码质量下滑的时候，及时修复问题，否则只会获得一堆低质量代码