JavaScript中通过prototype将类嵌入另一类的使用场景有哪些

你贴的代码是JS里非常朴素的依赖注入实现，没有用什么黑魔法，核心就是解决类之间强绑定带来的灵活性问题。

常见实际使用场景 #

• 插件化架构开发：比如写通用组件、核心框架类的时候，很多非核心功能不想硬编码进主类。比如一个通用表格类Table，默认的导出功能、排序功能类都可以通过原型挂载的方式接入，不同业务线用的时候，可以挂自己定制的导出逻辑、排序逻辑，不用改Table类的核心源码。
• 解决循环依赖报错：如果A类和B类分属两个文件，互相引用的时候，ES Module或者CommonJS的加载机制很容易出现某一方拿到undefined的情况，等两个类都完成初始化之后再往原型上挂依赖，就能绕开加载顺序导致的引用错误。
• 单元测试场景：测试A类的方法时，如果依赖的B类会触发真实接口请求、操作DOM等副作用，不需要改A类源码，直接在测试用例里给A原型挂一个写死返回值的Mock B类，就能快速隔离依赖做单测，测完还原原型即可。
• 按需加载优化：核心类A需要首屏加载，但依赖的B类是只有用户触发特定操作（比如点高级编辑按钮）才会用到的重逻辑，就可以先不把B打包进首屏资源，等动态加载完B的脚本之后，再把B挂到A原型上，有效降低首屏包体积。
• 多态定制场景：同一个A类在不同场景下需要用不同版本的B实现，比如PC端挂PC端适配的B类，移动端挂移动端适配的B类，不需要写一堆if判断在A类内部，直接在初始化阶段给原型挂对应场景的B即可。

为什么要在类定义完之后再往原型挂载，不直接在类内部引用B？ #

核心原因就两个字：解耦。
如果直接在A的printFooBFromA方法里写死new B()，A和B就完全绑定死了：

1. 你要换一个B的子类、或者换Mock实现做测试，必须改A类的源码，违反开闭原则。
2. 如果B类的脚本加载顺序在A后面，A类定义的时候B还不存在，直接写new B()会直接抛引用错误。
3. 挂在原型上的属性会顺着原型链被继承，子类继承A的时候可以直接重写自己原型上的B属性，不会影响父类的原有逻辑，甚至你可以给单个A实例单独挂定制的B类，完全不影响其他实例，灵活度比硬编码高很多。

注：这种写法比把B挂成A的静态属性（也就是A.B = B）更符合JS的原型继承逻辑——实例可以通过this.B直接拿到依赖，不需要在方法里硬编码写A.B，子类继承的时候也不需要额外处理静态属性的继承问题。

内容的提问来源于stack exchange，提问作者milanHrabos