设计原则

包括SOLID五大基础原则（单一职责、开闭、里氏替换、接口隔离、依赖倒置），复合设计原则（合成复用原则、迪米特法则​、无环依赖原则），其他补充原则（高内聚低耦合原则、KISS/YAGNI原则、CAP定理）

SOLID 原则

单一职责原则(SRP)规定类和方法应仅承担单一职责，通过职责分离降低系统耦合度。典型实践案例包括SpringMVC框架中控制器、服务层与持久层的严格分层设计。
开闭原则(OCP)要求系统对扩展开放而对修改关闭，通过抽象类和接口实现功能扩展，如输入法皮肤模块通过抽象基类实现多套皮肤的热插拔更换。
里氏替换原则(LSP)强调子类必须能够完全替代基类而不改变系统原有功能，违反该原则的典型案例包括正方形类继承长方形类后破坏面积计算逻辑。
接口隔离原则(ISP)主张建立专用接口替代臃肿接口，如成绩管理系统将录入、统计、分析等功能拆解为独立接口避免"胖接口"问题。
依赖倒置原则(DIP)规定高层模块应依赖抽象而非具体实现，典型案例是通过定义数据转换接口实现业务模块与数据源的具体实现解耦。

复合设计原则

合成复用原则 (CARP)优先采用对象组合而非继承实现代码复用，如汽车分类设计通过引擎、底盘等部件的组合方式优于继承体系构建。
迪米特法则(LoD)限定对象仅与直接朋友类通信。指如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。说明通过中间层减少耦合度的实现机制。
无环依赖原则 (ADP)消除模块间的循环依赖关系，确保系统架构的层级化组织，典型案例包括通过接口抽象打破数据库模块与日志模块的相互依赖链。

其他补充原则

高内聚低耦合原则作为结构化设计的核心理念，要求模块内部元素紧密相关（高内聚），模块间依赖最小化（低耦合），常用实现方式包括信息隐藏和接口隔离。
KISS/YAGNI原则 KISS（保持简单）原则反对过度设计，YAGNI（不需则不实现）原则强调仅开发当前必需功能，两者共同指导开发者避免冗余设计。
CAP定理应用在分布式系统设计领域，CAP定理指明一致性、可用性、分区容错性三者不可兼得的特性，衍生出最终一致性等设计准则。

UML

1. 用例图（Use Case Diagram）： 描述系统的功能需求以及与外部参与者（Actors）的交互。

2. 类图（Class Diagram）： 显示系统中类的属性、操作以及类之间的关系。

3. 对象图（Object Diagram）： 类图的实例，展示对象之间的交互和关系。

4. 包图（Package Diagram）： 展示不同包的组织结构以及包之间的关系。

5. 组件图（Component Diagram）： 描述系统的物理结构，展示组件以及它们之间的关系。

6. 部署图（Deployment Diagram）： 展示系统的物理部署，包括硬件、节点以及它们上运行的软件组件。

7. 状态图（Statechart Diagram）： 描述对象所有可能的状态以及状态之间的转换。

8. 活动图（Activity Diagram）： 展示业务流程或操作的工作流程，表示步骤和决策点。

9. 序列图（Sequence Diagram）： 展示对象之间交互的时间顺序，包括消息传递和对象生命周期。

10. 通信图（Communication Diagram）： 类似于序列图，但更侧重于显示对象之间的关系而不是时间顺序。

11. 时间图（Timing Diagram）： 展示在时间上的对象状态变化和约束。

12. 交互概览图（Interaction Overview Diagram）： 组合使用其他交互图（如序列图和通信图）来提供更高层次的交互视图。

口诀

用例显需求，类图看结构， 对象实例化，包图组织强， 组件物理分，部署硬件上， 状态变化记，活动流程忙， 序列时序清，通信关系网， 时间顺序排，交综更上层。

这个口诀尝试覆盖UML的主要图类型，每一句对应一种或几种UML图：

• 用例显需求：用例图展示系统功能需求。
• 类图看结构：类图展示系统的类结构。
• 对象实例化：对象图展示类实例之间的关系。
• 包图组织强：包图展示系统的组织结构。
• 组件物理分：组件图展示系统的物理组件。
• 部署硬件上：部署图展示系统的物理部署。
• 状态变化记：状态图展示对象的状态和状态转换。
• 活动流程忙：活动图展示业务流程或操作。
• 序列时序清：序列图展示对象间交互的时间顺序。
• 通信关系网：通信图展示对象间的通信关系。
• 时间顺序排：时间图展示时间顺序和约束。
• 交综更上层：交互概览图提供高层次的交互视图。

设计模式

单工象建原、77桥外享组理、访备责观模状命迭策

1. 创建型模式（Creational Patterns）

这些设计模式提供了创建对象的机制，增加了已有代码的灵活性和可复用性。

• 单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。
• 工厂方法模式（Factory Method）：定义创建对象的接口，让子类决定实例化哪一个类。
• 抽象工厂模式（Abstract Factory）：创建相关或依赖对象的家族，而不需明确指定具体类。
• 建造者模式（Builder）：构建一个复杂的对象，并允许按步骤构造。
• 原型模式（Prototype）：通过拷贝现有的实例创建新的实例，而不是通过新建。

2. 结构型模式（Structural Patterns）

这些设计模式处理对象组合的问题，让不同的对象和类可以以多种方式组合和复用。

• 适配器模式（Adapter）：允许对象间的接口不兼容问题得以解决。
• 装饰器模式（Decorator）：动态地给一个对象添加额外的职责。
• 代理模式（Proxy）：为其他对象提供一种代理以控制对它的访问。
• 外观模式（Facade）：为子系统中的一组接口提供一个一致的界面。
• 桥接模式（Bridge）：将抽象部分与它的实现部分分离，使它们可以独立地变化。
• 组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构。
• 享元模式（Flyweight）：通过共享来高效地支持大量细粒度的对象。

3. 行为型模式（Behavioral Patterns）

这些设计模式专注于对象间的通信，帮助将算法和行为封装在对象中。

• 策略模式（Strategy）：定义一系列算法，把它们一个个封装起来，并使它们可互换。
• 模板方法模式（Template Method）：在方法中定义算法的骨架，延迟到子类中实现。
• 观察者模式（Observer）：对象间的一对多依赖关系，当一个对象改变时，所有依赖于它的对象都会被通知并自动更新。
• 迭代器模式（Iterator）：顺序访问一个聚合对象中的各个元素，不暴露其内部的表示。
• 责任链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。
• 命令模式（Command）：将请求封装为一个对象，从而使用户可用不同的请求对客户进行参数化。
• 备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
• 状态模式（State）：允许一个对象在其内部状态发生改变时改变其行为。
• 访问者模式（Visitor）：为一个对象结构（如组合结构）增加新能力。

口诀

"用例类包组件，部署状态活动，序列通信时间，交综包罗万象。"

这句话中包含了UML的大部分主要图表类型：

• 用例：用例图
• 类包：类图和包图
• 组件：组件图
• 部署：部署图
• 状态：状态图
• 活动：活动图
• 序列：序列图
• 通信：通信图
• 时间：时间图
• 交综：交互概览图

https://baijiahao.baidu.com/s?id=1827854329089840264&wfr=spider&for=pc

架构风格&架构模式

架构风格（Architecture Style）

名称	英文	核心概念 / 特点	适用场景
单体架构	Monolith / REST	整个应用作为一个整体部署，模块间调用紧密；通常有单一数据库和单一进程	小型应用、早期 MVP 项目
事件驱动	Event Driven / Clean	系统通过事件通信解耦模块，模块之间通过事件总线或消息队列异步交互	高并发、分布式系统、微服务
微服务	Microservices / CQRS	系统拆分为多个小服务，每个服务独立部署、独立数据库，通过 API 通信；CQRS 强调“读写分离”	大型系统、复杂业务
六边形架构	Hexagonal / SCS	核心业务逻辑（Domain）与外部接口（UI、数据库、消息队列）解耦，通过端口和适配器访问	需要高可测试性、解耦外部依赖
微内核架构	Microkernel / SOA	核心功能提供最小化内核，其他功能通过插件或服务扩展；SOA 是服务导向	插件式系统、企业应用集成
空间型架构	Layered / 分层	系统按照职责分层（表现层、业务层、数据层），层间调用清晰	几乎所有企业应用
主从架构	Master-Slave / 主从	数据或任务分配上有主节点和多个从节点，主节点负责协调	数据同步、分布式存储、数据库复制

---

架构模式（Architecture Pattern）

名称	英文	核心概念 / 特点	适用场景
MVC	Model-View-Controller	分离数据模型（Model）、视图（View）、控制器（Controller）；常用于 Web 和桌面应用	Web 前端、桌面应用
MVP	Model-View-Presenter	Presenter 替代 Controller，负责中间逻辑，View 尽量被动	前端 UI 层复杂交互，WinForms/Android
MVVM	Model-View-ViewModel	ViewModel 绑定数据到 View，自动更新 UI，支持双向绑定	前端框架（Vue、Angular、React + MobX）
DDD	Domain Driven Design	聚焦于业务领域模型，强调领域驱动，业务逻辑清晰，模型与代码高度一致	复杂业务系统、企业级应用

---

使用要点

架构风格 → 系统级

想“整个系统怎么组织和通信”，关注单体 / 微服务 / 事件驱动 / 分层。

架构模式 → 模块级 / UI 层级

想“模块怎么分层或绑定”，关注 MVC / MVP / MVVM / DDD。

关键词法：

单体 = 一块

微服务 = 拆小块

事件 = 异步通知

六边形 = 核心 + 适配器

主从 = 一个管多个

MVC/MVP/MVVM = 数据、逻辑、界面分工

DDD = 业务逻辑为王

---

MVC 🆚 MVP

MVC

Controller 调度，View 可以主动观察 Model，适合简单应用。

数据流：用户 → Controller → Model → View

MVP

Presenter 控制一切，View 被动，适合复杂界面、需要高可测试性的应用。

数据流：用户 → View → Presenter → Model → Presenter → View