嘉兴网站建设与管理专业,苏州做管网gis的网站,做乡村旅游的网站,网站开发三层结构Unity 设计模式 之 【什么是设计模式】/ 【为什么要使用设计模式】/ 【架构和设计模式的区别】 目录
Unity 设计模式 之 【什么是设计模式】/ 【为什么要使用设计模式】/ 【架构和设计模式的区别】
一、简单介绍
二、 Unity 设计模式
1、Unity 开发中使用设计模式的特点
2…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。 七大设计原则 开闭原则面对需求对程序的改动是通过增加新代码进行的而不是改变原来的标题依赖倒转原则高层模块不应该依赖底层模块两个都应该依赖与抽象抽象不应该依赖于细节细节应该依赖于抽象。所以要针对接口编程不要针对实现编程。里氏代换原则由于使用基类对象的地方都可以使用子类对象因此在程序中尽量使用基类类型来对对象进行定义而在运行时再确定其子类类型用子类对象来替换父类对象单一职责原则一个对象应该只包含单一的职责并且该职责被完整地封装在一个类就一个类而言应该仅有一个引起它变化的原因接口隔离原则接口隔离原则是指使用多个专门的接口而不使用单一的总接口。每一个接口应该承担一种相对独立的角色不多不少不干不该干的事该干的事都要干合成复用原则合成复用原则就是指在一个新的对象里通过关联关系包括组合关系和聚合关系来使用一些已有的对象使之成为新对象的一部分新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之要尽量使用组合/聚合关系少用继承迪米特法则一个软件实体应当尽可能少的与其他实体发生相互作用。在类的结构设计上每一个类都应当尽量降低其成员变量和成员函数的访问权限
