前言super是什么？
兴许很多人，如果没有面向对象开发教训，都不是很分明。
包含我。
起因
之前在我的项目中应用class，没有用到继承，都是间接申明一个类，应用的时候，new一个实例，很简略，但逻辑不是很清晰。
明天有一个想法，把根底性能抽离进去，做成基类，业务逻辑继承根底性能。这样有两个益处，一个就是根底性能能够做成多个我的项目通用，另一个就是便于业务拆分。其实说到底，就是解耦。
通过
之前有多个性能，都写在box类，我的项目入口就在box。
现在从box抽出了一个基类lib，一个业务入口business，还有很多细分的业务模块business-xx。
我的项目入口改为business，business继承lib，引入business-xx，实例化business-xx。
代码如下：
import Rail from './rail'class Business extends Lib { constructor(){ this.rail = new Rail(this) }}然而很遗憾，报错：this hasn't been initialised - super() hasn't been called
这是说我没有执行super？
搜了一下，原来这是调用父类的构造方法，加了一行代码：
super()而后还是报错，不过这次不是语法报错，是代码赋值谬误，因为在父类的构造方法中，须要参数。
思考了一下，在super中传递了几个参数，父类的构造函数控制台打印，果然就是super中的参数。
很显然，super的确是调用父类的构造方法，而且能够传递参数。
后果
代码如下：
import Rail from './rail'class Business extends Lib { constructor(control){ super(control) this.rail = new Rail(this) }}这样，只有在我的项目的开始，实例化Business，就能够把对应的性能注册进来，比方rail。
而且前面如果须要增加性能，只须要如rail一样，注册一次就行。
因为Business继承自Lib，又把Business传递到了业务模块外部，所以在业务模块外部齐全能够获取到Lib的办法和属性。control是整个大模块Business和内部模块通信的桥梁。
结语
已经想过，每一个业务子模块，比方rail，间接继承自Lib，而后也是在Business中实例化。这样会不会更适合呢？
然而起初否决了这种想法，毕竟不同子业务模块之间也存在通信的需要，如果做得太过独立，通信也很麻烦。
不如全副子模块都挂载在Business中，通信不便。
模块化，也有肯定的界线吧。