设计模式-设计原则

28 阅读5分钟

设计模式-设计原则

本文主要介绍下设计模式的作用、六种设计原则以及优缺点,设计模式帮助开发者在面对复杂性时做出更优的设计决策,帮助开发者创建更健壮、灵活和易于维护的代码。

供自己以后查漏补缺,也欢迎同道朋友交流学习。

引言

最近在梳理前端的一些知识体系,发现漏掉了比较重要的设计模式,所以打算整理下,方便以后查漏补缺。

本文主要介绍下设计模式的作用、六种设计原则以及优缺点,后面会根据分类详细介绍设计模式的三大类型,以及每种类型的设计模式。

设计模式的原则

设计模式的原则帮助开发者在面对复杂性时做出更优的设计决策,并且很多设计模式都是基于这些原则来构建的。

设计模式的六大原则是面向对象编程中的基础概念,它们帮助开发者创建更健壮、灵活和易于维护的代码。

单一职责原则

单一职责原则(Single Responsibility Principle, SRP)定义一个类应该只有一个引起它变化的原因,即一个类只负责一项职责。

前端应用场景

在前端开发中,比如你可以将用户界面逻辑与业务逻辑分离。也可以为不同的组件定义清晰的责任范围,如数据获取、状态管理、UI渲染等,每个组件专注于处理自己的任务,从而简化了维护和测试工作。

开闭原则

开闭原则(Open/Closed Principle, OCP)定义软件实体(类、模块、函数等)应该是可扩展的,但不可修改

前端应用场景

当需要添加新功能时,尽量避免直接修改已有的代码。例如,可以通过高阶组件(HOC)或者 Hooks 来增强现有组件的功能,而不是直接修改原始组件的实现,这样既增加了代码的复用性,又降低了引入错误的风险。

里氏替换原则

里氏替换原则(Liskov Substitution Principle, LSP)定义子类必须能够替换其基类而不影响程序的正确性。

前端应用场景

在使用组件继承时,确保子组件的行为不会破坏父组件的预期行为,保持一致性和稳定性。

接口隔离原则

接口隔离原则(Interface Segregation Principle, ISP)定义客户端不应该被迫依赖于它们不使用的接口。

前端应用场景

例如,在构建微前端架构时,确保各个微前端之间通过明确定义且最小化的接口进行通信,减少不必要的耦合。

依赖倒置原则

依赖倒置原则(Dependency Inversion Principle, DIP)定义高层模块不应依赖于低层模块,二者都应依赖于抽象;抽象不应依赖于细节,细节应依赖于抽象。

前端应用场景

使用依赖注入服务定位器模式来解耦高层逻辑与具体实现。利用依赖注入机制,使服务组件之间的交互更加灵活,便于单元测试和维护。

迪米特法则

迪米特法则(Law of Demeter, LoD)定义对象间应该尽可能少地了解彼此(最少知道原则),限制对象间的直接交互。

前端应用场景

在前端开发中,尤其是在大型应用中,遵循迪米特法则可以帮助降低各部分之间的耦合度。例如,父组件中通过 props 传递必要的信息给子组件,而不是允许子组件直接访问父组件的状态或方法,从而提高代码的封装性和可维护性。

设计模式的作用

设计模式的作用主要有以下几个方面:

  • 提高可复用性:提供一种标准化的解决方案,让开发者减少重复代码的编写,提高代码的复用率。
  • 提高可维护性:能够帮助开发者将复杂的问题分解为更小更易于管理的部分,使得代码结构更加清晰,便于理解和维护。
  • 提高可扩展性:采用抽象封装等技术手段,将实现细节与高层策略分离,使得系统更加灵活,能够更容易地适应需求的变化和功能的扩展。
  • 促进团队协作与沟通:设计模式为开发者提供了一套通用的术语和概念,使得团队成员之间能够更有效地沟通和协作。
  • 提高软件质量:采用设计模式可以避免一些常见的设计错误和陷阱,降低软件缺陷的风险,从而提高软件的整体质量。

设计模式的优缺点

优点

  • 提高代码的可复用性可维护性可扩展性
  • 使代码更加灵活,易于修改扩展
  • 有助于更好地组织和管理代码结构

缺点

  • 可能会增加系统的复杂性
  • 在某些情况下可能会导致代码的冗余
  • 需要一定的设计模式知识和经验才能正确使用。

设计模式学习专栏系列

项目地址