JavaScript全讲-架构原则解析

Posted 2020-09-26 liguangsunls

因为近期一直在忙，非常久没有更新，见谅。

上篇我们讲完javascript函数式编程的特性，今天我们就来聊聊JavaScript中的架构。

提到JavaScript架构。非常多人会认为不可思议，由于架构多是针对类似Java这样的强语言，而JavaScript一直被看成是弱语言，它有设计模式，能够用来构建架构吗？

答案无疑是肯定的！

设计模式本身是一种非常重量级的东西。当JavaScript被当做辅助使用时。谈架构反而会添加复杂度！

所以这么多年。大家并没有看到JavaScript关于设计模式。架构之类的文章。

而现今Web的发展，前端越来越重要，自然而然会推动JavaScript关于设计模式。架构方面的发展。

因为JavaScript和Java的截然不同，在讨论设计模式时。我们不能直接套用Java中关于设计模式的解说方法。而是从还有一方面来解说。

设计模式的SOLID原则鼎鼎大名，今天我们就通过SOLID原则来透析JavaScript中的架构。

1. 单一职责（Single Responsibility）

简单说，就是一个类仅仅要负责一种职责就可以，假设有多个职责须要处理，那就分离另外一个类。

之前我们有讲过JavaScript的面向对象特性，通过对象的封装，我们能够把单一职责在一个对象实现就可以。这就完美符合了单一职责。

这么说起来。非常多程序猿肯定会非常歧视，这有什么好说的？ 事实上单一职责表面上非常easy，不论什么人都能信手拈来，可是它作为设计原则中最基础的原则。是有原因的！

封装并不困难。困难的是在不论什么时候能准确的分离职责。举个样例：

单就系统登录功能。我们把它作为一个职责来看！ 可是随着需求的复杂。会有很多其它的情况出现:

加入了验证码功能，要不要分离职责？

加入用户有效期验证，要不要分离？

添加用户邮箱验证功能，要不要分离？

假设你一直不分离。随着需求的添加，你会被拖入万劫不复的境界，不要觉得这是危言耸听！ 可是反过来说，要怎样分离，怎样做到恰到优点的分离，是须要多年软件经验才干做到的。

基础招式的出神入化。虽不能让你杀敌于千里之外。但会让你立于不败之地！

2. 开闭原则，对扩展开放。对改动关闭（Open Close）

这个原则听起来比較含蓄。通常程序的表现形式是继承！ 即有一个公共的父类，不论什么子类想要实现特殊的需求，都仅仅要重写或者添加方法就可以。实现起来，就是设计模式中的模板方法。别名钩子方法。

JavaScript是支持继承的。

我们就用伪代码来解释怎样实现模板方法。而且在子类中重写。

这样的方式是开闭原则最直接的体现。 从伪代码能够体会到。仅仅要基础功能不变，我们都不须要改动Base类。而仅仅要扩展其功能就可以。

3. 里氏替换原则（Liskov Substitution）

听起来更加含蓄了。用简单的话说。就是不要瞎搞！ 

就如上面的样例，你的需求FormView大部分都能实现，所以须要继承FormView。可是你又有一个需求，功能和FormView压根不沾边。可是你强行继承FormView。所有重写来来实现自己的代码，这就是乱搞了。

 里氏替换，就是在不论什么时候，用父类直接取代子类，都能实现大部分功能。上面的乱搞方式，父类根本不能替换子类使用，就违背了该原则。

4. 接口隔离（Interface Segregation）

同单一职责思想差点儿相同，单一职责是面向内部，即怎样分离职责。而接口隔离。是怎样提供更好的外部接口。

这个外部不是指WebService形式的接口。而是指类向外暴露的功能接口。

说简单点，就是不要让一个类过于庞大混乱，仅仅负责一部分功能。让其它使用的人能够清晰的分辨。

5. 依赖倒置（Dependence Inversion）

高层不能依赖底层。事实上非常多人并不能什么叫高层，什么叫底层。这样学术的话。仅仅能误导非常多的新手。

我们简单来说：这里的高层和底层就如建大厦，高层假设是23层，那么底层就是22层。建大厦时。23层一定要依赖于22层（这不是废话吗）

那么。套用到软件中。功能A和功能B，功能A依赖功能B，即功能A中须要调用B的接口，那么我们能够说：功能A是依赖于功能B。功能A是高层。功能B是底层。

那么怎样理解“不能依赖”呢？ 大厦的23层假设不能依赖22层。那不是扯淡吗？

在软件中。一个模块过多依赖于其它模块。那么它就是一团乱麻的中心点。为什么这么说呢？

假如模块A依赖非常模块。伪代码就例如以下

这种代码在软件后期对开发人员就如噩梦一般。B C D模块的不论什么改动都有可能引起A代码的改动。可能非常多开发人员说，我的功能非常easy，不会改动的！

假设是这样。基本证明你的软件，要么不是给人用的，要么就是没人用！

那么假设我们不能直接使用依赖，要怎样处理这样的代码引用呢？

伴生依赖倒置的模式，就是依赖注入！这个可真是大名鼎鼎，Spring的基础之中的一个。没有它，在如今来说，我们根本没办法写代码了。

它的核心思想也非常easy。类似于我们去吃自助餐。我想吃牛扒，直接去拿就好了，不用我去烹饪。

用程序的语言来讲，我想吃牛扒，是我要依赖牛扒，本来我要亲手new一个牛扒。可是这时候因为有了厨师。我直接拿来吃就能够了。所以别名依赖倒置。

假设这时候，我都不用去拿牛扒，厨师直接送过来，这叫依赖注入！

我的牛扒吃完之后。师傅拿回去。直接给别人再继续吃，这叫单例注入，尽管有点恶心，可是非常高效率！万一上面有异物（被别人改动了），这叫单例污染！

师傅每天预先做10个牛排，谁要给谁送去！这叫单例池，类似于连接池。

依赖注入在在我们平时的开发中处处可见，这里大家仅仅要理解其思想就可以。接下来。我们就要讲讲在JavaScript中怎样实现依赖注入了？这里仅仅用其伪代码实现其简单的思想

随着各种JS MVC框架的流行，依赖注入也在前端越来越流行，眼下做的最好的就属AngularJS！有兴趣的同学能够深入学习。

上面五个原则的首字母拼在一起就是SOLID。构成了软件稳固的架构。

大家可能会发现五个原则都是非常easy的原理，事实也确实如此。可是熟练掌握而且灵活运用到软件中，却不是一件简单的事情。尤其他的表现形式-设计模式。复杂多变。非常多更是雌雄同体，根本分不清楚，让我们困恼不堪，同一时候又让广大程序猿欲罢不能，真真是痛并快乐着。

JavaScript作为面向对象的语言，具备实现架构的条件。类似BackBone，AngularJS等MVC框架已经逐渐引领前端。

随着它们的持续发展。前端开发终将像Java一样可控，这对全部开发者都是一大福音。

最后送给全部程序猿一句话：假设你想的太多，那是由于你代码写的太少。