JavaScript 私有成员与继承冲突：Symbol 解决私有方法调用异常

JavaScript 私有成员与继承冲突：Symbol 解决私有方法调用异常

本文旨在探讨一个常见的开发陷阱。

首先引入一个具体场景：在 JavaScript 代码中，BusinessView 类需要执行两项布局任务，分别针对表单和地图进行布局处理。

在 JavaScript 社区中，通常约定使用下划线 _ 前缀来标识私有成员，但这仅是一种开发规范。

class BaseView {
layout() {
console.log("BaseView Layout");
}
}
class BusinessView extends BaseView {
layout() {
super.layout();
this._layoutForm();
this._layoutMap();
}
_layoutForm() {
// ....
}
_layoutMap() {
// ....
}
}

基于继承的 OOP 实践与异常现象

随着业务扩展，发现多个视图类都涉及地图布局功能。为了复用代码，采用继承模式，从 BusinessView 中抽离出地图相关逻辑，构建一个名为 MapView 的基类。

class MapView extends BaseView {
layout() {
super.layout();
this._layoutMap();
}
_layoutMap() {
console.log("MapView layout map");
}
}
class BusinessView extends MapView {
layout() {
super.layout();
this._layoutForm();
this._layoutMap();
}
_layoutForm() {
// ....
}
_layoutMap() {
console.log("BusinessView layout map");
}
}

上述代码体现了典型的基于继承的面向对象编程思想，初衷是让不同层级的类通过 layout() 方法各自负责相应的布局任务。然而，实际运行 JavaScript 代码时会出现异常：BusinessView._layoutMap() 被执行了两次，而 MapView._layoutMap() 却从未执行。这是为什么呢？

原型链机制与虚函数对比分析

这涉及到虚函数的概念。

在 JavaScript 中，如果祖先类和子孙类定义了同名方法，系统默认调用子孙类中的方法。若需调用祖先类的同名方法，必须在子孙类中通过 super. 关键字显式调用。

我们可以深入分析这一执行过程。

当创建子类对象时，其自身类及所有祖先类的定义均已加载。此时：

• 调用 BusinessView.layout() 方法。
• 该方法内部找到 super.layout()，进而开始调用 MapView.layout()。
• 在 MapView.layout() 方法内部执行 this._layoutMap() 调用
  • 接着，从当前对象（即 BusinessView 实例）中查找 _layoutMap() 方法。
  • 由于 BusinessView 中定义了 _layoutMap，系统直接找到并调用它。

由此可见，因为 BusinessView 定义了 _layoutMap，JavaScript 引擎根本不会去搜索原型链。这正是基于原型关系的面向对象编程的局限性所在。如果我们参考 C# 的处理流程，会发现机制有所不同：

• 首先调用 BusinessView.layout()。
• 找到 base.layout()，开始调用 MapView.layout()。
• 在 MapView.layout() 方法内部执行 this._layoutMap() 调用
  • 在 MapView 类中查找 _layoutMap()。
  • 验证目标方法是否具备虚函数特性
    • 如果存在，则向子类查找最后一个重载（override）函数并调用。
    • 如果不存在，则直接调用当前找到的方法。

区别的关键在于对“虚函数”的判断机制不同。

那么，这与私有成员有何关联？因为在 C# 中，如果将 _layoutMap 定义为私有，它就不是虚函数。因此，MapView.layout() 调用时，必然执行 MapView._layoutMap()，而不会被子类覆盖。

虚函数的概念较为复杂，但可以简化理解为：若一个成员方法被声明为虚函数，调用时会沿虚函数链找到最后一个重载版本进行执行。

JavaScript 中虽然约定 _ 前缀代表私有，但这只是“君子之约”，实质上该方法并非真正私有。这种约定对人类开发者有效，但计算机并不知晓此约定。如果 JavaScript 实现了真正的私有成员，系统会识别 _layoutMap() 为私有方法，从而只调用本类中的定义，而不受子类定义的影响。

利用 Symbol 和闭包实现私有成员

接下来探讨如何解决当前的私有化问题。

尽管 JavaScript 目前缺乏原生的私有成员支持，但我们需要一种即时有效的解决方案。可以使用 Symbol 和闭包来实现这一目标。

请注意，这里的闭包并非指在函数内部生成闭包，请继续阅读后续内容。

首先重新审视私有化问题：目标是让祖先类在调用某个方法时，不会去子类中寻找覆盖版本。从语法层面无法直接解决，因为 JavaScript 的设计就是从具体实例向前查找指定名称的方法。但如果找不到该方法名呢？

之所以能找到，是因为方法名通常是字符串，而字符串在全局作用域中具有相同的含义。ES2015 引入了 Symbol，它必须通过实例化创建，且每次实例化都代表唯一的标识符。如果将类定义在闭包中，并在该闭包内声明一个 Symbol 作为私有成员的名称，问题即可解决。例如：

const MapView = (() => {
const _layoutMap = Symbol();
return class MapView extends BaseView {
layout() {
super.layout();
this[_layoutMap]();
}
[_layoutMap]() {
console.log("MapView layout map");
}
}
})();
const BusinessView = (() => {
const _layoutForm = Symbol();
const _layoutMap = Symbol();
return class BusinessView extends MapView {
layout() {
super.layout();
this[_layoutForm]();
this[_layoutMap]();
}
[_layoutForm]() {
// ....
}
[_layoutMap]() {
console.log("BusinessView layout map");
}
}
})();

而在现代基于模块的定义中，甚至无需显式使用闭包，因为模块系统会自动封闭作用域。

const _layoutMap = Symbol();
export class MapView extends BaseView {
layout() {
super.layout();
this[_layoutMap]();
}
[_layoutMap]() {
console.log("MapView layout map");
}
}
const _layoutForm = Symbol();
const _layoutMap = Symbol();
export class BusinessView extends MapView {
layout() {
super.layout();
this[_layoutForm]();
this[_layoutMap]();
}
[_layoutForm]() {
// ....
}
[_layoutMap]() {
console.log("BusinessView layout map");
}
}

经过上述改革后的代码，即可按预期输出结果：

BaseView Layout
MapView layout map
BusinessView layout map

最后进行总结。

笔者在多年的开发实践中，养成了分析和解决问题的思维习惯，能够迅速透过现象看到实质问题，并基于现有条件加以解决。Symbol 出现的原因之一正是为了解决私有化问题，但关键在于理解为何使用以及如何正确使用，这需要深入的分析和思考。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。