1. 创建型模式：

• 涉及对象创建机制，旨在创建对象的同时隐藏创建逻辑。如：工厂方法（Factory Method），抽象工厂（Abstract Factory），建造者（Builder），原型（Prototype），单例（Singleton）。

  2. 结构型模式：

• 涉及类和对象的组合，构建出大的结构。如：适配器（Adapter），桥接（Bridge），组合（Composite），装饰器（Decorator），外观（Facade），享元（Flyweight），代理（Proxy）。

  3. 行为型模式：

• 涉及类的对象之间的通信。如：命令（Command），中介者（Mediator），观察者（Observer），状态（State），策略（Strategy），模板方法（Template Method），访问者（Visitor）。

  1. 单一责任原则（SRP）：

• 一个类应该只有一个发生变化的原因。

  2. 开闭原则（OCP）：

• 软件实体应当对扩展开放，对修改关闭。

  3. 里氏替换原则（LSP）：

• 子类对象应该能够替换掉它们的父类型对象。

  4. 接口隔离原则（ISP）：

• 多个专用接口比一个宽泛用途的接口要好。

  5. 依赖倒转原则（DIP）：

• 高层模块不应该依赖于低层模块，它们都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。

  6. 合成/聚合复用原则（CARP）：

• 它强调优先使用对象组合/聚合，而不是通过类继承来达到软件复用的目的。这样做可以提高系统的灵活性和可维护性，因为组合/聚合关系比继承关系更松耦合，更易于管理和扩展。

  7. 迪米特法则（LoD）：

• 主张一个对象应当对其他对象保持最少的了解，即每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

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

• 描述：一个类应该只有一个引起变化的原因。这意味着一个类应该只负责一项功能或业务逻辑，避免将过多的职责放在一个类中，从而增加类的复杂性和耦合度。
• 好处：提高代码的可读性、可维护性和可测试性；降低类的复杂性和耦合度；增加类的内聚性。

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

• 描述：软件实体（类、模块、函数等）应该是可扩展，而不可修改的。也就是说，当需要添加新功能时，应该通过扩展现有代码来实现，而不是修改现有代码。
• 好处：提高系统的稳定性和可扩展性；减少对现有代码的破坏和潜在错误；促进代码复用。

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

• 描述：子类必须能够替换其父类并且出现在父类能够出现的任何地方，而程序的行为不变。这意味着子类在扩展父类功能的同时，不能破坏父类原有的功能和行为。
• 好处：保证继承体系的正确性和稳定性；增强代码的可替换性和可复用性。

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

• 描述：客户端不应该依赖它不需要的接口。这意味着接口应该尽量细化，每个接口只负责一项功能或业务逻辑，避免接口过于臃肿和庞大。
• 好处：提高系统的灵活性和可维护性；减少接口的耦合度和实现难度；促进接口的复用和组合。

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

• 描述：高层模块不应该依赖低层模块，它们都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。这意味着在代码设计中，应该尽量使用接口和抽象类来定义依赖关系，而不是直接使用具体的实现类。
• 好处：降低代码之间的耦合度；提高系统的可维护性和可扩展性；促进代码的复用和替换。

  6. 合成/聚合复用原则（Composite/Aggregate Reuse Principle, CARP）

• 描述：尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的。合成和聚合都是将已有对象纳入新对象中，使之成为新对象的一部分，但新对象可以独立于已有对象而存在。继承则是一种强耦合的关系，父类与子类之间通常存在“是一种”的关系，这限制了复用的灵活性。
• 好处：降低类之间的耦合度，因为组合或聚合使每个类更独立，职责更清晰；提高系统的灵活性，因为组合和聚合允许在运行时动态地改变对象的行为和属性；增强代码的可维护性，因为组合和聚合使得类的结构更加清晰，易于理解和修改。

  7. 迪米特法则（Law of Demeter, LoD）或最少知识原则（Least Knowledge Principle, LKP）

• 描述：一个对象应当对其他对象保持最少的了解。这意味着在代码设计中，应该尽量减少对象之间的直接交互和依赖，通过引入中介者或者消息传递等方式来降低对象之间的耦合度。
• 好处：提高系统的模块化和可维护性；减少对象之间的耦合度和依赖关系；增加代码的可读性和可测试性。

 除了上面提到的原则，还有一些原则如下：

  1. 面向接口编程：

• 面向接口编程（Interface-oriented programming，IOP）是一种编程方法论，强调程序设计应基于接口而不是具体的实现。在面向接口编程中，类和模块之间的耦合关系不是通过具体的类来实现，而是基于接口来进行交互和依赖。

  2. 一个类需要的数据应该隐藏在类的内部：

• 将数据和对数据的操作封装在一个类的内部，通过访问控制修饰符（如 private、protected）限制外部对数据的直接访问，只允许通过类定义的接口（方法）进行访问。

  3. 类这间应该零耦合，或者只有传导耦合。换句话说，类之间没有关系，要么只使用另一个类的接口提供的操作：

• 在面向对象编程中，尽量以传导耦合为目标，降低模块之间的依赖关系，减少因修改一个模块而引起对其他模块的影响。这可以通过合理的接口设计、抽象化、依赖注入等手段来实现。另外，利用设计模式和设计原则，如依赖倒置原则（DIP）、最少知识原则（LKP）等，也有助于减小模块之间的耦合，使得系统更易维护、扩展和测试。

  4. 在水平方向尽可能统一地分布系统功能：

• 实现系统功能的均衡负载和高可伸缩性。这种设计方法可以将系统功能分布到多个相同或相似的节点上，以实现更好的性能和可靠性。

  1. 可视化：

• 通过将系统抽象为图形化的表示，模型使得系统的结构和行为更容易被理解和沟通。

  2. 分析：

• 通过对模型进行分析，可以检查系统是否满足需求，识别潜在的问题，以及优化系统的设计。

  3. 文档化：

• 模型可以作为系统开发过程中的重要文档，帮助团队成员了解系统的设计和实现。

  4. 指导开发：

• 模型可以作为开发过程中的指导，帮助开发者按照预定的设计进行编码和测试。

  1. 结构化图形：

• 类图（Class diagrams）：用于描述系统中的类、接口、以及它们之间的关系，如继承、实现、关联等。
• 对象图（Object diagrams）：展示系统中对象的实例以及它们之间的关系。
• 包图（Package diagrams）：描述系统的模块结构和包之间的依赖关系。
• 组件图（Component diagrams）：描述系统的物理结构，包括软件组件以及它们之间的关系。
• 部署图（Deployment diagrams）：展示系统的硬件结构，包括节点以及它们之间的通信关系。

  2. 行为式图形：

• 活动图（Activity diagrams）：用于描述系统的动态行为，包括业务流程、并行活动以及活动间的约束关系。
• 状态图（State diagrams）：描述系统中对象的生命周期和状态转移，以及状态之间的转换条件。
• 用例图（Use case diagrams）：从用户角度描述系统的功能需求，包括参与者、用例以及它们之间的交互关系。

  3. 交互性图形：

• 顺序图（Sequence diagrams）：描述系统中对象之间的交互，强调交互发生的时间顺序。
• 通信图（Communication diagrams）：展示对象之间的消息传递顺序和协作关系。
• 交互概述图（Interaction overview diagrams）：用于描述多个交互图之间的关系。

  1. 可视化和描述系统结构：

• UML能够以图形方式表示系统的结构，包括类、对象、组件、模块、子系统等，帮助开发人员更清晰地了解系统的组成部分。

  2. 描述系统行为和交互：

• UML可以描述系统的动态行为和对象间的交互，包括消息传递顺序、并行活动、业务流程等，有助于开发人员理解系统的运行方式和交互逻辑。

  3. 设计和模型转换：

• 使用UML，开发人员可以在设计阶段进行模型转换，将高级的概念转换为具体的实现，从而更好地组织和规划开发工作。

  4. 文档化和沟通：

• UML图表提供了一种标准的、易于理解的方式来描述系统，可以作为开发团队之间的沟通工具，促进团队成员之间的协作和理解。