从事开发岗位也有一年多的时间了,见识过陈年老项目,也从零到一搭建过一个项目。随着项目和业务的不断扩张,写下的代码如果没有进行设计,就渐渐变成了 emm … x 山,怎么写都不对劲,过段时间就想着重构。
人之所以可以走到食物链的顶端,是因为会学习、总结,会使用“名字”和“工具”。而设计模式并不是凭空发明出来的,是经过了大量的项目实践总结出来的对某种业务场景下的程序编写最佳实践,总结出来的解决方案,并给它取了个名字,就变成了一个设计模式。就好比篮球场上的战术,组织后卫常喊出打几号战术,而不是一个人一个人地指挥,简洁的代号往往比冗杂的描述更优雅。有可能你经常写程序的一种方式,可以描述出来,但不知道它叫什么名字,有可能就是一种设计模式。所以我们在学习的过程中,经常会有这种感受: ooooo !!这玩意儿我经常用,经常这么写,原来这个是 xx 模式!
最后,为什么要学设计模式呢?虽然有时候设计模式会使代码复杂度升高,增加开发的成本,但极大地降低了维护成本。就好比图书馆中的书如果无序地散落在各个角落,找起来如同大海捞针;而如果标号且归类、有序地放在指定书架上,找起来就容易了许多。想象一个场景,某天,你指着一段代码开始骂,这谁写的 x 山!鼠标移了上去, git 修改记录显示,哦!我写的,那没事了。赶紧设计模式学起来,优雅地编写简洁、可复用、易维护的程序 ~
init() { console.log('My name is ', this.name); } } const p1 = new createPerson('lebron'); const p2 = new createPerson('james'); p1.init(); // My name is lebron p2.init(); // My name is lebron
// 代理单例 classPerson{ constructor(name) { this.name = name; } init() { console.log('My name is ', this.name); } }
classcreatePerson{ constructor(name) { if (!createPerson.instance) { createPerson.instance = new Person(name); } return createPerson.instance; } } const p1 = new createPerson('lebron'); const p2 = new createPerson('james'); p1.init(); // My name is lebron p2.init(); // My name is lebron
最终版本
每次实现一个类的单例模式都去 CV 重复的模板代码,不太符合预期。
于是,我们可以根据设计模式的原则“找出程序变化的地方,并将变化封装起来”
可以做如下改造
classSingleTon{ constructor(fn) { let singleInstance; functionsingleConstructor(...args) { // 第一次实例化 if (!singleInstance) { singleInstance = new fn(...args); } // 多次实例化直接返回 return singleInstance; }
classPerson{ constructor(name) { this.name = name; } init() { console.log('My name is ', this.name); } } const createPerson = new SingleTon(Person); const p1 = new createPerson('lebron'); const p2 = new createPerson('james'); p1.init(); // My name is lebron p2.init(); // My name is lebron console.log(p1 === p2); // true