Unity 计划模式 之 【什么是计划模式】/ 【为什么要使用计划模式】/ 【架构 ...

Unity 计划模式 之 【什么是计划模式】/ 【为什么要使用计划模式】/ 【架构和计划模式的区别】


目录
Unity 计划模式 之 【什么是计划模式】/ 【为什么要使用计划模式】/ 【架构和计划模式的区别】
一、简单先容
二、 Unity 计划模式
1、Unity 开发中使用计划模式的特点
2、Unity 中常用的计划模式
3、Unity 开发中使用计划模式的优势
4、Unity 和其他环境使用计划模式的区别总结
三、什么是软件框架，软件框架和计划模式的区别
软件框架和计划模式的区别：
四、开发计划中为什么要使用计划模式
1. 解决常见题目，提升开发效率
2. 促进代码的可维护性
3. 提高代码的可扩展性
4. 增强代码的可复用性
5. 促进团队协作，改善沟通
6. 降低系统的耦合性
7. 应对变化，提高系统的机动性
8. 克制代码重复
五、计划模式 什么时候使用，怎么使用合适
1. 何时使用计划模式
1.1 当代码重复时
1.2 当系统需要扩展时
1.3 当类和对象的依赖关系过于复杂时
1.4 当需要应对变化时
1.5 当计划不符合SOLID原则时
2. 如何合适地使用计划模式
2.1 识别需求
2.2 克制过度计划
2.3 遵循简单优先原则
2.4 保持机动性
2.5 组合使用计划模式
2.6 关注可测试性
2.7 学习经典案例
3. 常见计划模式的使用场景
3.1 单例模式（Singleton）
3.2 工厂方法模式（Factory Method）
3.3 观察者模式（Observer）
3.4 计谋模式（Strategy）
3.5 装饰者模式（Decorator）
六、23 种计划模式
1、创建型模式（5种）
2、布局型模式（7种）
3、行为型模式（11种）

---

一、简单先容

计划模式 是指在软件开发中为解决常见题目而总结出的一套 可复用的解决方案。这些模式是经过长期实践证明有用的 编程经验总结，并可以在差别的项目中复用。计划模式并不是代码片段，而是对常见题目的 抽象解决方案，它提供了代码布局和模块间交互的一种计划思绪，帮助开发者解决特定的计划题目。
   计划模式的特点：
  

• 通用性：计划模式针对的是软件开发中常见的计划题目，适用于各种软件工程项目。
  
• 可复用性：计划模式可以在差别项目和环境下被重复使用，提高代码的可维护性和扩展性。
  
• 可扩展性：计划模式有助于让代码布局更加机动，易于扩展和修改。
  
• 模块化：通过计划模式，可以减少代码的耦合性，增强模块间的独立性。
  
• 提高沟通效率：计划模式为开发者提供了一种通用的计划语言，使得团队成员能够快速理解并讨论计划方案。
  

  
二、 Unity 计划模式

在 Unity 开发中使用计划模式 和在其他环境或平台上使用计划模式的核心原理是雷同的。计划模式是软件计划中的通用解决方案，用于解决特定的计划题目，无论在哪个开发环境中，其本质都稳固。然而，在 Unity 中使用计划模式与在其他开发平台上的应用有一些独特的差异和需要注意的地方，主要与 Unity 的游戏架构和组件化计划相干。

1、Unity 开发中使用计划模式的特点

• 组件化架构和游戏对象：
  
  
  
  • Unity 的核心计划是基于 GameObject-Component 体系，开发者通过将各种组件附加到游戏对象上来界说游戏逻辑。这种架构天然支持将代码功能分解成多个独立的模块，这和许多计划模式的目的非常同等，尤其是单一职责和松耦合原则。
    
  • 比方，在传统的面向对象编程中，继续是常见的组织代码的方式，而在 Unity 中，组合（Composition）更为普遍，开发者可以通过将差别的组件组合到一个游戏对象上，创建丰富的行为。这和某些计划模式（如计谋模式）的头脑相近，计谋模式鼓励通过组合差别计谋来改变对象行为，而不是通过继续。
    
  
  
• Unity 的生命周期与 MonoBehaviour：
  
  
  
  • MonoBehaviour 是 Unity 中的基础脚本类，许多脚本类通过继续它来实现游戏逻辑。MonoBehaviour 提供了一组生命周期方法，如 Start()、Update()、OnTriggerEnter() 等，用来管理脚本的实行顺序。
    
  • 在 Unity 中使用计划模式时，必须考虑 Unity 的这种生命周期管理。比方，单例模式在其他环境下可能涉及懒加载或复杂的初始化逻辑，而在 Unity 中，单例对象通常会与 DontDestroyOnLoad 方法联合，确保它在场景切换时不被烧毁。
    
  
  
• 游戏开发的及时性：
  
  
  
  • 及时性是游戏开发中的关键因素，Unity 开发中往往需要处理大量及时的输入输出、物理运算、渲染等。在这种环境下，计划模式的使用需要考虑到性能开销。比方，在使用观察者模式时，观察者的数目和频率可能会影响游戏的帧率，所以需要特别小心管理订阅与通知的机制。
    
  
  
• 脚本与引擎的精密联合：
  
  
  
  • 在 Unity 中，脚本和引擎的底层功能精密联合，比方物理引擎、渲染系统、动画系统等。因此，计划模式在使用时通常需要与 Unity 提供的 API 协同工作。
    
  • 比方，在实现工厂方法模式时，开发者可能需要通过 Unity 的 Instantiate() 方法动态创建游戏对象，而不是直接使用面向对象编程中的 new 操作符。这意味着在 Unity 中使用某些计划模式时，需要借助 Unity 的特定工具和功能。
    
  
  

2、Unity 中常用的计划模式

• 单例模式 (Singleton)
  
  
  
  • 应用场景：用于全局管理器类，如 GameManager、AudioManager，确保全局状态在整个游戏生命周期中唯一且可访问。
    
  • Unity 特点：通常联合 DontDestroyOnLoad() 方法来保证在场景切换时，单例对象不会被烧毁。
    
  
  
• 工厂方法模式 (Factory Method)
  
  
  
  • 应用场景：用于动态生成游戏对象，如敌人、道具等。通过工厂方法，可以根据游戏逻辑在差别时间点生成差别类型的对象。
    
  • Unity 特点：通常联合 Instantiate() 方法来生成对象的实例，并从资源中加载预制件（Prefab）。
    
  
  
• 观察者模式 (Observer)
  
  
  
  • 应用场景：用于处理变乱机制，如 UI 按钮点击、游戏中角色生命值变化、AI 变乱等。
    
  • Unity 特点：可以使用 Unity 的变乱系统（如 UnityEvent），或自行管理观察者列表。
    
  
  
• 状态模式 (State)
  
  
  
  • 应用场景：用于控制对象的状态切换，尤其是在角色动画、AI 行为树等场景中非常有用。
    
  • Unity 特点：可以联合 Unity 的 Animator 状态机，管理复杂的状态切换。
    
  
  
• 计谋模式 (Strategy)
  
  
  
  • 应用场景：用于动态改变对象行为，如差别武器或攻击方式、差别移动方式等。
    
  • Unity 特点：可以通过将差别的行为封装为独立的脚本组件，并根据需要动态添加或移除组件，来实现机动的行为切换。
    
  
  
• 下令模式 (Command)
  
  
  
  • 应用场景：用于实现打消操作、输入控制器、行为记载等。
    
  • Unity 特点：可以联合 Unity 的输入系统来实现一系列下令的实行和打消操作。
    
  
  

3、Unity 开发中使用计划模式的优势

• 提高代码复用性：计划模式有助于将复杂的功能拆解为可复用的组件。比方，通过工厂模式和预制件，开发者可以动态生成各种对象，而不必重复编写对象初始化代码。
  
• 增强代码的可维护性和扩展性：比方，通过状态模式管理角色状态，使得后期修改或添加新的状态变得更加容易，而不需要重写或修改大量代码。
  
• 符合 Unity 组件化计划：Unity 强调通过组件组合实现复杂功能，这与很多计划模式（如计谋模式、装饰模式）的思绪不谋而合。通过使用这些计划模式，开发者能够更加机动地组织代码，使其更符合 Unity 的框架布局。
  
• 减少耦合性：计划模式如观察者模式可以减少差别模块之间的耦合，使代码布局更为疏松，方便以后扩展或维护。
  

4、Unity 和其他环境使用计划模式的区别总结

特性	Unity 中使用计划模式	其他开发平台中使用计划模式
组件化架构	基于 GameObject 和 Component 体系，倾向于组合而非继续	传统面向对象编程中常使用继续，较少接纳组合
生命周期管理	受 MonoBehaviour 生命周期的影响，计划模式可能需要顺应这种布局	自由管理对象的创建与烧毁，生命周期不依赖于引擎
及时性需求	游戏开发中需要高效管理计划模式，克制性能题目	其他系统中，及时性要求相对较低，计划模式对性能影响较小
引擎和 API 交互	需要联合 Unity API，如 Instantiate()、Animator 等	大多数情况下依赖于标准库和 API，自由度较高
场景切换和数据持久化	计划模式需要考虑跨场景的数据管理，如使用 DontDestroyOnLoad()	常规应用中，数据管理不需要考虑场景切换，通常依赖数据库等持久化

总之，Unity 中的计划模式应用与传统开发环境有一些区别，主要体现在 Unity 的组件化架构和生命周期管理上。开发者需要根据 Unity 的独特特性来调解计划模式的实现方式，以便更好地与 Unity 引擎协同工作。通过合理使用计划模式，开发者可以创建更具扩展性、可维护性和复用性的代码，同时提高开发效率和代码质量。

三、什么是软件框架，软件框架和计划模式的区别

软件框架 是一个 可复用的代码布局或库，它为软件开发提供了一个 基本的骨架和通用功能，开发人员可以在此基础上进行扩展和定制，以满足特定应用的需求。框架通常提供一组标准化的接口、类和工具，帮助开发者快速开发应用程序，而不需要从零开始编写底层代码。
   软件框架的特点：
  

• 可复用性：框架提供了大量可复用的组件和模块，使开发者无需重复开发常见功能。
  
• 约定优于设置：框架通常包含默认的约定和最佳实践，开发者只需遵循框架的约定，便可克制大量的设置工作。
  
• 控制反转（Inversion of Control, IoC）：在框架中，控制权通常从开发者转移到框架。框架会自动管理应用程序的流程和生命周期，开发者只需在特定点扩展代码。
  
• 简化开发流程：通过提供常见功能的实现，如数据库交互、UI 渲染、网络通信等，框架简化了开发流程，提高了开发效率。
  
• 扩展性：开发者可以在框架的基础上扩展功能，框架通常答应定制和扩展特定模块。
  

  
  计划模式：
  计划模式是 通用的、可复用的解决方案，用于解决软件计划中的特定题目。计划模式是一种高层次的计划思绪，是对编程中常见题目的总结和抽象。
  
软件框架和计划模式的区别：

特性	Unity 中使用计划模式	其他开发平台中使用计划模式
组件化架构	基于 GameObject 和 Component 体系，倾向于组合而非继续	传统面向对象编程中常使用继续，较少接纳组合
生命周期管理	受 MonoBehaviour 生命周期的影响，计划模式可能需要顺应这种布局	自由管理对象的创建与烧毁，生命周期不依赖于引擎
及时性需求	游戏开发中需要高效管理计划模式，克制性能题目	其他系统中，及时性要求相对较低，计划模式对性能影响较小
引擎和 API 交互	需要联合 Unity API，如 Instantiate()、Animator 等	大多数情况下依赖于标准库和 API，自由度较高
场景切换和数据持久化	计划模式需要考虑跨场景的数据管理，如使用 DontDestroyOnLoad()	常规应用中，数据管理不需要考虑场景切换，通常依赖数据库等持久化

总之，两者之间的主要区别在于，框架是一种可以直接使用的工具和代码库，而计划模式则是对软件计划的经验总结，提供了一种组织代码的模式和思绪。
   

• 软件框架 是更具 现实性 的工具，它为开发者提供了代码实现和通用功能，可以直接使用，通常用于开发某一类型的应用程序。
  
• 计划模式 是一种 理论性的计划方案，用于引导如何计划代码布局，解决开发中反复出现的题目。计划模式强调的是计划原则和布局，不提供直接的代码实现。
  

  
四、开发计划中为什么要使用计划模式

在软件开发中使用计划模式的主要目的是为了提高代码的 可维护性、可扩展性 和 复用性。计划模式提供了经过验证的、可重复使用的解决方案，帮助开发人员克制常见的计划题目，简化开发过程。详细来说，使用计划模式有以下几个主要缘故原由：
   1. 解决常见题目，提升开发效率

  计划模式是经过实践查验的通用解决方案，针对常见的计划寻衅提供了标准化的方法。通过应用这些模式，开发人员不必从零开始计划解决方案，可以直接借用已有的模式来解决雷同题目，从而提高开发效率。
  2. 促进代码的可维护性

  计划模式帮助开发人员构建更加清晰的代码布局，减少复杂性，方便后期的维护和修改。比方，使用单例模式可以确保系统中的某个类只有一个实例，克制了全局状态混乱，便于管理。而观察者模式则可以帮助系统模块之间疏松耦合，易于扩展和维护。
  3. 提高代码的可扩展性

  计划模式鼓励使用接口和抽象类来解耦模块，使系统的各个部分独立演化。比方，工厂方法模式和抽象工厂模式通过创建对象的接口，将实例化对象的详细类与使用这些对象的代码分离，答应轻松扩展或更改系统功能，而不破坏现有代码。
  4. 增强代码的可复用性

  计划模式使代码具备更高的复用性。许多计划模式通过封装变化的部分，使得代码可以在差别场景下复用。好比，计谋模式将算法和详细实现分离，可以动态替换差别的算法，而无需修改客户端代码，从而增强了代码的复用本事。
  5. 促进团队协作，改善沟通

  计划模式是一种通用的计划语言，使用计划模式可以促进团队成员之间的沟通。差别的开发者在讨论系统计划时，通过提及详细的计划模式（如代理模式或装饰者模式），能够快速理解相互的计划意图，减少沟通障碍。
  6. 降低系统的耦合性

  计划模式通过将模块之间的交互疏松耦合，降低了系统各部分之间的依赖性。比方，观察者模式可以实现模块之间的疏松耦合，使得一个模块的变化不会影响其他模块，从而提高系统的机动性和可扩展性。
  7. 应对变化，提高系统的机动性

  计划模式帮助开发人员构建顺应变化的系统。软件开发中，需求经常发生变化，计划模式通过提供机动的布局，使得系统可以更容易地顺应这些变化。比方，状态模式答应对象在状态变化时切换行为，克制了大量的if-else语句。
  8. 克制代码重复

  计划模式提供了标准的解决方案，可以克制重复实现雷同功能的代码。比方，模板方法模式界说了算法的骨架，答应子类重写某些步骤，而无需重复整个算法的实现，减少了代码重复，提高了代码的同等性。
  总之，使用计划模式不仅能够解决常见的计划题目，还可以提升代码的可读性、可维护性和扩展性，帮助开发人员创建机动、易于修改的系统。同时，它们作为一种通用的开发语言，能促进团队协作和沟通，使开发工作更加高效。

五、计划模式 什么时候使用，怎么使用合适

使用计划模式 的关键在于解决特定的软件计划题目，而不但是为使用而使用。选择适当的计划模式可以提高代码的质量和开发效率。要知道什么时候使用和如何合适地使用计划模式，必须基于题目的性质、软件的复杂度、团队协作需求等。以下是一些原则和使用建议：
   1. 何时使用计划模式

  1.1 当代码重复时

  当你发现系统中存在重复代码时，可以考虑使用计划模式来减少重复。比方，如果多个地方都在实现相似的对象创建逻辑，你可以使用工厂方法模式来同一对象的创建逻辑。
  1.2 当系统需要扩展时

  如果系统在未来可能需要扩展，那么计划模式可以帮助构建机动的架构。比方，计谋模式答应你轻松添加新的算法或操作，而不修改现有代码；装饰者模式答应你动态扩展对象的功能，而不影响其他对象。
  1.3 当类和对象的依赖关系过于复杂时

  当你发现类之间的依赖关系过于精密，难以维护或扩展时，计划模式可以帮助解耦。好比，观察者模式可以使类之间疏松耦合，克制直接依赖；中介者模式可以会合管理对象间的交互，减少直接的依赖。
  1.4 当需要应对变化时

  如果你预见到系统某些部分会频繁变化，而其他部分则相对稳固，那么可以使用计划模式来隔离变化。比方，状态模式适用于当对象状态变化时需要改变其行为的场景，克制了硬编码多个if-else语句。
  1.5 当计划不符合SOLID原则时

  计划模式能帮助你遵循SOLID原则（单一职责、开闭原则、里氏替换、接口分离、依赖倒置）。比方，依赖倒置原则可以通过使用依赖注入和抽象工厂模式来实现，减少高层模块对低层模块的依赖。
  2. 如何合适地使用计划模式

  2.1 识别需求

  起首，清楚理解题目或需求。不要盲目使用计划模式，除非它能解决特定的题目。每种计划模式都有其特定的应用场景。比方：
  

• 如果你的系统需要支持差别的产物创建过程，使用工厂模式。
  
• 如果你需要为一个对象动态地添加行为，可以考虑装饰者模式。
  
• 如果你的对象需要根据差别的状态体现出差别的行为，使用状态模式。
  

  2.2 克制过度计划

  计划模式的使用应当有针对性。过度使用计划模式可能会使系统复杂化，增加代码的阅读和维护成本。仅在需要时使用计划模式，不要为了炫技或寻求模式而引入不必要的复杂性。比方，单例模式固然简单，但如果过度使用，可能导致全局状态共享，增加调试难度。
  2.3 遵循简单优先原则

  始终优先选择简单而清晰的计划方案。如果某个题目可以通过简单的继续或组合来解决，那么没有必要引入复杂的计划模式。计划模式是解决复杂题目的工具，但不要让模式增加不必要的复杂性。
  2.4 保持机动性

  使用计划模式时要考虑到系统的未来扩展。计划模式应当是机动的，克制硬编码逻辑。比方，计谋模式答应你动态替换算法，而不是写死逻辑，如许可以机动地顺应变化的需求。
  2.5 组合使用计划模式

  在复杂的系统中，偶然需要组合多种计划模式来解决题目。比方，工厂模式可以与单例模式组合使用，确保创建的对象是单例的；或者将观察者模式和中介者模式联合使用，管理多个观察者的交互。
  2.6 关注可测试性

  计划模式还能提升代码的可测试性。通过使用依赖注入或工厂方法模式，可以让代码依赖于接口而不是详细实现，从而更容易进行单元测试和替换依赖。
  2.7 学习经典案例

  学习常见的计划模式应用场景和经典案例，尤其是在已有的框架或库中。比方，Java 中的java.util.Observer接口实现了观察者模式，Spring 框架中广泛使用的依赖注入机制基于依赖倒置原则和工厂模式。
  3. 常见计划模式的使用场景

  3.1 单例模式（Singleton）

  

• 使用场景：确保某个类只有一个实例，比方数据库连接池或设置管理类。
  
• 如何使用：控制类的实例化，提供全局访问点。
  

  3.2 工厂方法模式（Factory Method）

  

• 使用场景：当需要创建对象但不想显式指定对象的类时。
  
• 如何使用：界说一个用于创建对象的接口，将详细的对象创建工作推迟到子类。
  

  3.3 观察者模式（Observer）

  

• 使用场景：当一个对象状态发生变化时需要通知其他对象，如变乱监听系统。
  
• 如何使用：界说一对多的依赖关系，一个对象状态变化时通知所有依赖对象。
  

  3.4 计谋模式（Strategy）

  

• 使用场景：当有多种算法可以替换且需要动态选择时，比方支付方式选择。
  
• 如何使用：界说一组算法，将它们封装在独立的类中，并通过接口进行交换。
  

  3.5 装饰者模式（Decorator）

  

• 使用场景：需要动态地给对象增加功能，而不影响其他对象时。
  
• 如何使用：用一个装饰对象包裹真实对象，在不改变对象布局的情况下增加新功能。
  

  总之，使用计划模式的关键在于精确理解题目的性质，联合计划模式的应用场景来做出合适的选择。要克制过度计划，保持代码简单，同时确保系统的机动性和可维护性。把握常见计划模式及其组合，能够帮助你应对复杂的软件计划题目，提升代码质量。

六、23 种计划模式

1、创建型模式（5种）

• 工厂方法模式（Factory Method）：界说一个接口用于创建对象，但让子类决定实例化哪一个类。
  
• 抽象工厂模式（Abstract Factory）：提供一个创建相干或依赖对象的接口，而不指定详细类。
  
• 单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。
  
• 建造者模式（Builder）：将对象的构建与其表示分离，以便雷同的构建过程可以创建差别的对象。
  
• 原型模式（Prototype）：通过复制现有的实例来生成新对象，而不是通过实例化类。
  

2、布局型模式（7种）

• 适配器模式（Adapter）：将一个类的接口转换为客户希望的另一个接口，使原本不兼容的类可以一起工作。
  
• 桥接模式（Bridge）：将抽象部分与它的实现部分分离，以使它们可以独立变化。
  
• 装饰者模式（Decorator）：动态地给一个对象添加新的职责，克制了创建子类的需要。
  
• 组合模式（Composite）：将对象组合成树形布局以表示部分-整体的层次布局，客户可以同样地对待单个对象和组合对象。
  
• 外观模式（Facade）：为子系统中的一组接口提供一个同一的接口，使得子系统更容易使用。
  
• 享元模式（Flyweight）：通过共享细粒度的对象来减少内存使用。
  
• 代理模式（Proxy）：为其他对象提供一个代理以控制对这个对象的访问。
  

3、行为型模式（11种）

• 模板方法模式（Template Method）：在一个方法中界说一个算法的骨架，而将一些步骤的实现延迟到子类中。
  
• 下令模式（Command）：将请求封装为对象，从而可以用差别的请求对客户进行参数化、列队或记载请求日志，以及支持可打消操作。
  
• 迭代器模式（Iterator）：提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示。
  
• 观察者模式（Observer）：界说对象间的一对多依赖，当一个对象改变状态时，其依赖者都会得到通知并自动更新。
  
• 中介者模式（Mediator）：界说一个对象来封装一系列对象之间的交互，中介者使各对象不需要显式地相互引用，从而使它们之间的耦合疏松，且可以独立地改变它们之间的交互。
  
• 备忘录模式（Memento）：在不破坏封装性的前提下，捕捉对象的内部状态，并在以后规复该状态。
  
• 解释器模式（Interpreter）：为某个语言界说一个语法表示，并界说一个解释器，使用该表示来解释语言中的句子。
  
• 状态模式（State）：答应对象在内部状态改变时改变它的行为，看起来对象好像修改了它的类。
  
• 计谋模式（Strategy）：界说一系列算法，将每一个算法封装起来，并让它们可以交换，计谋模式使得算法可以独立于使用它的客户而变化。
  
• 职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而克制请求的发送者和吸取者之间的耦合。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
  
• 访问者模式（Visitor）：表示一个作用于某对象布局中的各元素的操作，它使你可以在不改变各元素的类的前提下界说作用于这些元素的新操作。
  

在一样平常应用中，计划模式从来都不是单个计划模式独立使用的。在现实应用中，通常多个计划模式混合使用，你中有我，我中有你。下图完整地描述了计划模式之间的混用关系，希望对大家有所帮助。

七、七大计划原则（SOLID）

计划模式中的计划原则是软件计划的核心头脑，旨在帮助开发人员创建更具可维护性、可扩展性和机动性的代码布局。这些原则是计划模式的基础，引导我们如何编写高内聚、低耦合的代码。以下是计划模式中常见的计划原则：
   1. 单一职责原则 (Single Responsibility Principle, SRP)

  

• 界说：一个类只负责一项职责，应该只有一个引起它变化的缘故原由。
  
• 解释：每个类都应该有且只有一个功能或行为。如果一个类负担了过多的责任，修改一个功能可能会影响到其他功能，增加维护的复杂性。
  
• 实例：假设有一个类既负责文件的保存，又负责文件内容的格式化。这时应将它拆分为两个类：一个负责文件保存，一个负责格式化。
  

  2. 开闭原则 (Open/Closed Principle, OCP)

  

• 界说：软件实体（类、模块、函数等）应该对扩睁开放，对修改关闭。
  
• 解释：当需求发生变化时，应该通过扩展类的行为来应对新需求，而不是修改已有的代码。这减少了对现有代码的影响，克制引入新 bug。
  
• 实例：在处理差别类型的支付时，添加新的支付方式应该通过继续扩展，而不是修改现有的支付处理逻辑。
  

  3. 里氏替换原则 (Liskov Substitution Principle, LSP)

  

• 界说：所有引用基类的地方必须能透明地使用其子类对象。
  
• 解释：子类应该能够替换其基类，而不影响程序的精确性。换句话说，子类应该完全遵循基类的行为规范，不能违反基类的约定。
  
• 实例：如果基类 Animal 有一个方法 makeSound()，而 Dog 和 Cat 类继续了它，那么无论是 Dog 还是 Cat 对象，都应该能够被用作 Animal 类型，而不影响程序功能。
  

  4. 依赖倒置原则 (Dependency Inversion Principle, DIP)

  

• 界说：高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
  
• 解释：在计划中，应该尽量依赖抽象（接口或抽象类），而不是详细实现。如许可以减少类之间的耦合，使代码更加机动。
  
• 实例：一个高层模块 PaymentService 应该依赖于 IPaymentProcessor 接口，而不是详细的 PaypalProcessor 类。如许可以轻松替换差别的支付处理方式，而不需要修改 PaymentService 的代码。
  

  5. 接口隔离原则 (Interface Segregation Principle, ISP)

  

• 界说：客户端不应该依赖于它不需要的接口。
  
• 解释：应将大接口拆分为多个小接口，每个接口只包含客户端所需的方法。如许克制客户端实现冗余的接口方法，减少不必要的依赖。
  
• 实例：如果一个接口包含了太多职责，好比 IWorker 接口既有 work() 方法又有 eat() 方法，那么不相干的类会被迫实现不需要的方法。应该将 IWorker 接口分为 IWorkable 和 IEatable，分别界说差别职责的接口。
  

  6. 迪米特法则 (Law of Demeter, LoD)

  

• 界说：一个对象应该对其他对象有最少的相识。
  
• 解释：又称最少知识原则，它强调对象之间的低耦合。一个对象不应该直接操作或依赖于其他类的内部细节，只应该通过其直接依赖的对象进行通信。
  
• 实例：假设有一个类 Car，它有一个 Engine 对象。在计划时，Car 应该只通过 Engine 的公共接口与 Engine 交互，而不是深入访问 Engine 内部的子对象。
  

  7. 合成复用原则 (Composition Over Inheritance)

  

• 界说：尽量使用组合（对象包含关系）来实现功能，而不是通过继续。
  
• 解释：通过组合，将类的功能封装成独立的组件，克制继续带来的层级复杂性和继续耦合题目。组合可以实现更机动的对象行为扩展，而继续会造成类的高度依赖。
  
• 实例：假设你有一个类 Bird，而想创建会游泳的鸟类，应该使用一个 Swimming 组件来添加游泳功能，而不是通过继续多个类来实现（如 SwimmingBird）。
  

  七大计划原则  开闭原则面对需求，对程序的改动是通过增加新代码进行的，而不是改变原来的标题依赖倒转原则高层模块不应该依赖底层模块，两个都应该依赖与抽象；抽象不应该依赖于细节，细节应该依赖于抽象。所以要针对接口编程，不要针对实现编程。里氏代换原则由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行界说，而在运行时再确定其子类类型，用子类对象来替换父类对象单一职责原则一个对象应该只包含单一的职责，而且该职责被完整地封装在一个类，就一个类而言，应该仅有一个引起它变化的缘故原由接口隔离原则接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该负担一种相对独立的角色，不多不少，不干不应干的事，该干的事都要干合成复用原则合成复用原则就是指在一个新的对象里通过关联关系（包罗组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法到达复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继续迪米特法则一个软件实体应当尽可能少的与其他实体发生相互作用。在类的布局计划上，每一个类都应当尽量降低其成员变量和成员函数的访问权限
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。