最近几周没时间写博客，主要是一直花时间(顺便补了打越的999)在整理这个在公司内部分享用到的一个ppt以及文稿，做分享的一个目的是安利一下我写的框架，也算是来b站半年来主要花时间做的东西。另一个目的就是相当于一个总结与记录吧，学到的以及用到的知识只有总结成体系才不容易忘。第一次分享会也结束了，文稿基本定型，所以在博客这里分享给大家。内容比较多，分成上下两篇。

下篇谈平台设计大概需要注意哪些东西。

最近Vue发布了在即将到来的新版本产生的变化，其中提到的很重要的一点就是将用Proxy代替Object.defineProperty实现数据的响应式。正巧mobx从4升级到5的过程中也用Proxy重写了自己的响应式系统，可以看到这个ES6特性确实称得上是响应式实现首选，好处甚至大过对兼容性的考虑。过去由于兼容性原因没有深入使用这个特性的机会，现在看来有必要再好好了解一下。

观察者模式又叫发布/订阅模式，它定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主对象。当主对象的状态发生变化时就会通知所有观察者对象进行更新。

有些时候我们需要像某些对象发送请求，但还没有确定的接受者和响应操作。就像导演拍戏一样，只要一声action的请求，不同的工作人员就会根据初始的职责来进行各自的响应操作。将请求者和接收者完全解耦，将响应方法封装在接收者内通过命令激活，这就是命令模式。

在程序设计中，有时候需要生产大量细粒度的对象来表示数据，如果能发现这些对象中除了部分特殊参数外其他开销基本相同，就可以通过享元模式把特殊参数移动到外面，在创建对象时再传进来，大幅度减少需要实例化的对象数量。这是一种优化性能的设计模式。

职责链模式将多个有机会处理请求的对象串联起来，将请求者和接受者解耦并将请求从链的入口传入，直到有一个对象能处理它为止。

在现实生活中，万物之间都有着复杂的联系。程序设计中也是一样。当整个应用架构慢慢变大时，不可避免的会创建各种各样的对象。而各个对象之间往往存在一定联系，当改动一个对象是可能无意间就影响了其他对象的功能。如果意识到部分对象之间有复杂的关系，就可以考虑使用中介者模式来管理。

我们给对象添加新的功能经常会使用继承，但继承存在着一些缺点。一方面会增强父子类之间的耦合性。另一方面，父类的细节对子类也是可见的，破坏了父类的封装性。装饰者模式提供了比继承更灵活的解决方案。和继承相比，它采取的是一种动态包装的方法添加新功能，在程序运行时再给对象根据需要添加职责。

模板方法模式是一种基于继承的设计模式。事件万物总有相似之处，提取出相似点作为父类，提取出不同点作为子类来继承父类，就得到了有着相同特点的不同对象。然后将方法骨架延迟到子类中，这个方法就是针对这一类相同特点对象的模板方法。这种设计模式很好的体现了泛化的思想。

俗话说无规矩不成方圆。在现实生活中，无论什么团体都会有自己的一套规章制度来管理，就像军队一样，即使人数众多也能在集体活动时保持统一与协调。在程序设计中也是如此，有时候我们可能需要针对一个子元素相似的结构操作数据，这时候组合模式就派上用场了。

迭代器模式是一种很常见的模式，大部分语言都有了内置的迭代器实现，JS也不例外，从Array.prototype.forEach到ES6新增的专用迭代器都属于迭代器模式。下面我们来探究一下迭代器模式的封装方法。

状态模式主要用来满足某个对象内部存在不同表现的需求场景。可以说是一种针对相似功能的类的进一步的封装。当这个状态对象接受到请求时，再将请求委托到内部类，根据内部定义好的实现逻辑返回结果到状态对象再表现出来。

代理模式是业务场景中很常用的模式。关键在于当不方便直接访问一个对象时，提供一个替身对象来接受访问，然后通过替身对象的内部处理将请求转交给本体对象。

俗话说条条大路通罗马，在程序设计中不少问题也存在着多种解决方案。不同的解决方案虽然都是用来解决同一个问题，但由于场景不同最适合的方案也不一样，于是很自然的想到将解决方案分别封装起来在合适的场景替换使用。这就是策略模式。

弹出层是一个很常见的需求。在一个登录功能的设计中，我们都希望无论单击多少次登录按钮，这个弹窗都只会被创建一次。这里就适合用单例模式来创建。在JS中单例模式的应用也非常广泛，比如全局缓存，window对象等等。下面我就来谈谈在JS中单例模式的具体应用。