跳到主要内容

设计模式

更适合前端宝宝体质的设计模式指南，期望能不只是简单罗列各种设计模式，而是真的结合实际工作开发中，使用设计模式让代码变得更优雅，不定时更新～

设计模式境界​

《深入浅出设计模式（HFDP，Head First Design Pattern)》的作者说，使用设计模式有3个层次：

  • Beginner——初级的时候无处不用设计模式，认为用的模式越多，设计就越好
  • Intermediate——中级的时候知道何时该用什么设计模式，什么时候不该用
  • Zen——到了禅的境界，设计模式被用来简化设计，让设计更优雅

设计模式原则​

  • S – Single Responsibility Principle 单一职责原则
    • 一个程序只做好一件事
    • 如果功能过于复杂就拆分开，每个部分保持独立
  • O – OpenClosed Principle 开放/封闭原则
    • 对扩展开放，对修改封闭
    • 增加需求时，扩展新代码，而非修改已有代码
  • L – Liskov Substitution Principle 里氏替换原则
    • 子类能覆盖父类
    • 父类能出现的地方子类就能出现
  • I – Interface Segregation Principle 接口隔离原则
    • 保持接口的单一独立
    • 类似单一职责原则，这里更关注接口
  • D – Dependency Inversion Principle 依赖倒转原则
    • 面向接口编程，依赖于抽象而不依赖于具体
    • 使用方只关注接口而不关注具体类的实现

设计模式的常用场景​

设计模式在前端开发中的真正价值在于，帮助我们解决实际开发中的常见问题，提升代码的可维护性、可扩展性和清晰度，而不是为了使用设计模式而用设计模式。

场景一 代码重复​

当多个地方有类似的逻辑或功能时，使用设计模式可以抽象和复用代码，避免冗余。比如，多个组件可能需要类似的创建方式或者相似的处理逻辑，这时候可以通过工厂模式来减少重复的代码。

场景二 复杂的状态管理​

当应用中有多个组件依赖于同一状态时，状态的管理可能会变得复杂。此时，使用观察者模式可以帮助解耦状态和组件之间的关系，使得当状态变化时，所有依赖该状态的组件能够自动更新，而不需要手动触发每个组件的刷新。

场景三 模块间的紧耦合​

如果不同模块之间的依赖过于紧密，一旦修改一个模块，可能会导致其他模块的变化，从而影响整个系统的稳定性。通过依赖注入模式或接口隔离原则，可以使模块间的依赖关系更加松散，从而提高系统的灵活性和可扩展性。

场景四 需求频繁变化​

当系统需求不断变化时，尤其是新功能和需求不断加入，修改现有代码可能会影响整个系统的稳定性。使用开闭原则和策略模式等设计模式，可以在不修改现有代码的情况下，扩展新的功能和需求，保持系统的稳定性和可扩展性。

场景五 复杂的用户交互​

当用户交互非常复杂，涉及到多个状态或不同的操作时，使用设计模式可以将这些交互逻辑抽象出来，使得代码更加简洁易懂。比如，命令模式可以将不同的操作封装成独立的命令，使得每个操作的执行更加灵活和可控制。