外观模式

什么是外观模式 ?

外观模式是最常见的设计模式之一，它为子系统中的一组接口提供一个统一的高层接口，使子系统更容易使用。简而言之外观设计模式就是把多个子系统中复杂逻辑进行抽象，从而提供一个更统一、更简洁、更易用的 API。很多我们常用的框架和库基本都遵循了外观设计模式，比如 JQuery 就把复杂的原生 DOM 操作进行了抽象和封装，并消除了浏览器之间的兼容问题，从而提供了一个更高级更易用的版本。其实在平时工作中我们也会经常用到外观模式进行开发，只是我们不自知而已

兼容浏览器事件绑定

let addMyEvent = function (el, ev, fn) {
  if (el.addEventListener) {
    el.addEventListener(ev, fn, false);
  } else if (el.attachEvent) {
    el.attachEvent('on' + ev, fn);
  } else {
    el['on' + ev] = fn;
  }
};

封装接口

let myEvent = {
  // ...
  stop: (e) => {
    e.stopPropagation();
    e.preventDefault();
  },
};

场景

• 设计初期，应该要有意识地将不同的两个层分离，比如经典的三层结构，在数据访问层和业务逻辑层、业务逻辑层和表示层之间建立外观 Facade
• 在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观 Facade 可以提供一个简单的接口，减少他们之间的依赖。
• 在维护一个遗留的大型系统时，可能这个系统已经很难维护了，这时候使用外观 Facade 也是非常合适的，为系统开发一个外观 Facade 类，为设计粗糙和高度复杂的遗留代码提供比较清晰的接口，让新系统和 Facade 对象交互，Facade 与遗留代码交互所有的复杂工作

优缺点

优点

• 简化接口：外观模式提供了一个统一的高层接口，使得子系统的使用变得更加简单和直观。
• 提高可用性：通过隐藏复杂的子系统细节，外观模式使得用户更容易理解和使用系统。
• 降低使用复杂性：用户只需与外观接口交互，而不需要了解每个子系统的内部实现，从而减少了学习成本。

缺点

• 可能增加子系统之间的耦合：外观模式可能导致子系统之间的强耦合，因为它们依赖于外观提供的接口，可能会影响系统的灵活性和可维护性。
• 降低系统灵活性：过度依赖外观接口可能会限制系统的扩展性，使得在需要深入定制或优化时变得困难。
• 增加额外的层次：引入外观层可能会增加系统的复杂性，特别是在设计不够精细的情况下。
• 性能开销：额外的抽象层可能会带来轻微的性能损耗，尤其是在高性能要求的场景中。
• 可能违反开闭原则：如果外观模式设计不当，可能会导致在需要扩展功能时必须修改现有代码。

总结

外观模式是一种常见的设计模式，它为子系统中的一组接口提供一个统一的高层接口，使得子系统更易于使用。通过将复杂的子系统逻辑进行抽象，外观模式简化了接口，提高了可用性，降低了用户的学习成本。许多常用的框架和库（如 jQuery）都遵循了外观模式，以隐藏底层复杂性并提供更易用的 API。