从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）。 他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。因此架构师和工程师们发展出了一种全新的现代方式来解决这个问题，就是微服务架构。它虽然延续了分而治之的思想，但却是以全新的方式来实现的。 软件设计模式是解决软件设计中常见问题的通用、可复用的解决方案。设计模式让我们可以分享通用词汇并使用经实战检验的方案，以免重复造轮子。我先简单介绍下微服务架构。 通过阅读这篇文章，你会学到： 微服务架构 微服务架构的优势 微服务架构的劣势 何时使用微服务架构 最重要的微服务架构设计模式，包括其优缺点、用例、上下文、技术栈示例及可用资源。 “请注意，本清单中的大部分设计...

说到设计模式，大家想到的就是六大原则，23种模式。这么多模式，并非都要记住，但作为前端开发，对于前端出现率高的设计模式还是有必要了解并掌握的，浅浅掌握9种模式后，整理了这份文章。 那么，我们先了解六大原则 六大原则： 依赖倒置原则([Dependence Inversion Principle]())：高层(业务层)不应该直接调用底层(基础层)模块 [开闭原则]()(Open Close Principle)：单模块对拓展开放、对修改关闭 单一原则(Single Responsibility Principle)：单模块负责的职责必须是单一的 迪米特法则([Law of Demeter]())：对外暴露接口应该简单 接口隔离原则(Interface Segregation Principle)：单个接口(类)都应该按业务隔离开 里氏替换原则(Liskov Substitution Principle)：子类可以替换父类 六大原则也可以用六个字替换：高内聚低耦合。 高 层不直接依赖底层：依赖倒置原则 内 部修改关闭...

本篇内容适合对设计模式有些了解，但想更进一步了解设计模式在实际场景应用的读者，对于初学者，推荐以前带我入门设计模式的《JavaScript设计模式与开发实践》这本书。 一、设计模式原则 1. 单一职责原则：一个函数只做一件事，如果功能过于复杂就拆分开 2. 开发/封闭原则：对扩展开放，对修改封闭；增加需求时，扩展新代码，而非修改已有代码 3. 里氏替换原则：子类能覆盖父类 4. 接口隔离原则：保持接口的单一独立 5. 依赖倒转原则：面向接口编程，依赖于抽象而不依赖于具体；使用方只关注接口而不关注具体类的实现 二、创建型设计模式 1、工厂模式 实质：一个工厂对象负责创建其他对象，而具体的创建逻辑由子类决定 应用：根据参数，调用对应的插件 // 统计插件 class AnalyticsPlugin { init() { console.log("初始化统计插件"); } } // 日志插件 class LoggerPlugin { init() { console.log("初始化日志插件"); } } //

1引言 本文以一个实际案例来介绍在解决业务需求的路上，如何通过常用的设计模式来逐级优化我们的代码，以把我们所了解的到设计模式真实的应用于实战。 2背景 假定我们现在有一个订单流程管理系统，这个系统对于用户发起的一笔订单，需要你编写代码按照以下环节进行依次处理 注：本文不会对每个环节的实现细节进行描述，读者也不必了解这每个环节的实现，我们只需要关注代码架构设计 3第一次迭代 按照背景，我们如果不是打算if-else一撸到底的话，我们最合适使用的设计模式应该是 责任链模式 ，于是我们先打算用责任链模式来做我们的第一次迭代。 先整体看下类图： ![2dada0edf7ea4e429490e5612dcbf697 tplv-k3u1fbpfcp-jj-...

单例模式 单例模式是指一个类在一个进程中只有一个实例对象（但也不一定，比如Spring中的Bean的单例是指在一个容器中是单例的） 单例模式创建分为饿汉式和懒汉式，总共大概有8种写法。但是在开源项目中使用最多的主要有两种写法： 1、静态常量 静态常量方式属于饿汉式，以静态变量的方式声明对象。这种单例模式在Spring中使用的比较多，举个例子，在Spring中对于Bean的名称生成有个类AnnotationBeanNameGenerator就是单例的。 AnnotationBeanNameGenerator 2、双重检查机制 除了上面一种，还有一种双重检查机制在开源项目中也使用的比较多，而且在面试中也比较喜欢问。双重检查机制方式属于懒汉式，代码如下： public class Singleton {     private volatile static Singleton INSTANCE;  

一、什么是设计模式？ 设计模式是一套被反复使用、多数人知晓、经过分类编目的、代码设计经验的总结。它是为了可重用代码，让代码更容易的被他人理解并保证代码的可靠性。 设计模式实际上是“拿来主义”在软件领域的贯彻实践，它是一套现成的工具，拿来即用。下面来看一下设计模式的设计原则。 二、设计几个原则 单一职责原则、开放封闭原则、里式替换原则、接口隔离原则 、依赖反转原则 、最少知识原则。 下面我们一起来看看几种在前端领域常见的设计模式： 单例模式、工厂模式、策略模式、代理模式、适配器模式、观察者模式/发布-订阅模式 三、常见的设计模式及实际案例 单例模式 1. 什么是单例模式？ 单例模式 （Singleton Pattern）又称为单体模式，保证一个类只有一个实例，并提供一个访问它的全局访问点。也就是说，第二次使用同一个类创建新对象的时候，应该得到与第一次创建的对象完全相同的对象。 Vue中的单例模式 （1）Element UI Element UI是使用Vue开发的一个前端UI框架。Elemen

本文主要讲述我们如何通过一个主干业务流程承接多个业务场景并在数据上可适配到多端型多场景，实现在服务端高质量高效率的“包接口”。 一、背景 前台业务同学在业务承接过程中总是抱怨大部分业务无法通过设计模式来承接，写的代码是越来越没有追求，理由是我无法预测未来的业务的发展，且设计模式更多的是在框架或中间件中使用。然而设计模式是对能力抽象出的通用模式，从哲学的角度来看世间万物皆尘土，事物都是可以抽象出共同的本质的东西。所以，难道只有底层能力可以抽象，业务逻辑部分就不可以抽象了？必须可以才是啊。 在前台业务承接过程中除了能力可以抽象，还有可以抽象出业务流程，假设在有这样一些业务场景，品搜和图搜、直播间评论和点赞、公域直播会场和私域商详透直播等等，这些各领域内的业务流程“大同小异”，因此都可以抽象出通用的业务流程节点。 但是通常在一个主干流程需要承接的场景有很多，比如直播间互动这个主干流程包括了直播间评论、点赞、求讲解、看证书、进场等等场景，所以我们需要通过主要流程进行进行多场景承接。但是这样还不够，在面对多端型多场景的情况下需要处理返回不同的数据模型。 综上所述，我们如何通过一个...

本文从设计原则、创建型模式、结构型模式、行为模式四个方向讲述C 的设计模式。 设计原则 单一职责原则 定义：单一职责原则[1][1]，所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该 有且只有一个改变的原因。 bad case ：IPhone类承担了协议管理（Dial、HangUp）、数据传送（Chat）。 good case： 里式替换原则 定义：里氏代换原则[2][2](Liskov Substitution Principle LSP)，任何 基类 可以出现的地方， 子类一定可以出现。 bad case ：ToyGun继承了A

策略模式是一种应用广泛的行为型模式，核心思想是对算法进行封装，委派给不同对象来管理，本文将着眼于策略模式进行分享。 01概述 我们在进行软件开发时要想实现可维护、可扩展，就需要尽量复用代码，并且降低代码的耦合度，而设计模式就是一种可以提高代码可复用性、可维护性、可扩展性以及可读性的解决方案。 大家熟知的23种设计模式，可以分为创建型模式、结构型模式和行为型模式三大类。其中，行为型模式可用于描述程序中多个类和多个对象如何协作完成复杂的任务，涉及不同对象间的职责分配、算法的抽象化。策略模式是一种应用广泛的行为型模式，本文将着眼于策略模式进行学习分享。 02基本概念 策略模式的核心思想是对算法进行封装，委派给不同对象来管理。这样，我们就可以定义一系列算法，将每个算法封装到具...

本文将着眼于工厂模式，从简单工厂模式、工厂方法模式和抽象工厂模式出发，展开学习和深入探讨。 01概述 我们在进行软件开发时要想实现可维护、可扩展，就需要尽量复用代码，并且降低代码的耦合度，而设计模式就是一种可以提高代码可复用性、可维护性、可扩展性以及可读性的解决方案。 大家熟知的23种设计模式，可以分为创建型模式、结构型模式和行为型模式三大类。其中，创建型模式是对类的实例化过程进行抽象，从而将对象的创建和使用分离开。工厂模式属于创建型模式的范畴，本文将着眼于工厂模式，从简单工厂模式、工厂方法模式和抽象工厂模式出发，展开学习和深入探讨。 02基本概念 工厂模式的核心思想就是把创建对象和使用对象解藕，由工厂负责对象的创建，而用户只能通过接口来使用对象，这样就可以灵活应对变...

代理模式 所谓代理，是指它与被代理对象实现了相同的接口，客户端必须通过代理才能与被代理的目标类进行交互，而代理一般在交互的过程中（交互前后），进行某些特定的处理，比如在调用这个方法前做前置处理，调用这个方法后做后置处理。 代理又分为静态代理和动态代理两种方式，Spring的AOP采用的是动态代理的方式 Spring通过动态代理对类进行方法级别的切面增强，动态生成目标对象的代理类，并在代理类的方法中设置拦截器，通过执行拦截器中的逻辑增强了代理方法的功能，从而实现AOP。 关于动态代理可以看我之前的文章，写的很详细 ：[动态代理总结，你要知道的都在这里，无废话！](https://mp.weixin.qq.com/s?__biz=MzUyOTg1OTkyMA &mid=2247485541&idx=1&sn=371e92596b8e7ba47019b15767b18873&scene=21 wechat_redirect) 策略模式 我们前面讲到，Spring AOP是通过动态代理来实现的。 具体到代码实现，Spring支持两种动态代理实现方式，一种是JDK

一、是什么 策略模式（Strategy Pattern）指的是定义一系列的算法，把它们一个个封装起来，目的就是将算法的使用与算法的实现分离开来 一个基于策略模式的程序至少由两部分组成： 策略类，策略类封装了具体的算法，并负责具体的计算过程 环境类Context，Context 接受客户的请求，随后 把请求委托给某一个策略类 二、使用 举个例子，公司的年终奖是根据员工的工资和绩效来考核的，绩效为A的人，年终奖为工资的4倍，绩效为B的人，年终奖为工资的3倍，绩效为C的人，年终奖为工资的2倍 若使用 if 来实现，代码则如下： js var calculateBouns = function(salary,level) { if(level = 'A') { return salary 4; } if(level = 'B') { return salary 3; } if(level = 'C') { return salary 2;

一、是什么 单例模式（Singleton Pattern）：创建型模式，提供了一种创建对象的最佳方式，这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建 在应用程序运行期间，单例模式只会在全局作用域下创建一次实例对象，让所有需要调用的地方都共享这一单例对象，如下图所示： 从定义上来看，全局变量好像就是单例模式，但是一般情况我们不认为全局变量是一个单例模式，原因是： 全局命名污染 不易维护，容易被重写覆盖 二、实现 在 javascript 中，实现一个单例模式可以用一个变量来标志当前的类已经创建过对象，如果下次获取当前类的实例时，直接返回之前创建的对象即可，如下： JS // 定义一个类 function Singleton(name) { this.name