为什么很多明知js的OOP是假的，还不厌其烦地实现，而不使用OLOO风格？
说实话，很多人即便知道 JavaScript 的“伪”面向对象（prototypebased）和那些刻意模仿类（class）实现的模式，仍然乐此不疲地去实践，甚至觉得“真香”，这背后其实有一番挺有意思的逻辑和历史渊源。这并不是因为他们真的认为 JavaScript 是“真的”类继承，更多的是一种历史惯性、工具选择以及对特定编程范式在实际应用中的权衡。
首先，我们得回到 JavaScript 的诞生和早期发展。它最初被设计成一种简单、易于嵌入浏览器的脚本语言，用来增加网页的交互性。那时候，很多其他语言已经有了成熟的类继承模型，这在当时的开发者群体中是一种非常普遍和被接受的编程范式。当 JavaScript 想要提供类似的能力时，原型继承（prototypebased inheritance）是其核心机制。但正如你所说，原型继承和传统的类继承在本质上有很大区别，它更像是“委托”而非“继承”。
然而，当 JavaScript 逐渐从一个简单的脚本语言发展成一门功能强大、应用广泛的编程语言，尤其是在服务器端（Node.js）的崛起后，它的复杂性呈指数级增长。这时候，大量的开发者涌入 JavaScript 的生态圈，其中不乏习惯了 C++、Java、C 等传统面向对象语言的开发者。
对于这些开发者来说，JavaScript 的原型继承模型，尤其是早期那些直接操作 `__proto__` 或者 `prototype` 属性的写法，显得非常“奇特”和“反直觉”。他们需要花费额外的精力去理解这种基于委托的继承方式，这与他们熟悉的“类”的概念相去甚远。
于是，为了弥合这种“认知鸿沟”，也为了让 JavaScript 的开发体验更接近他们熟悉的模式，一些开发者开始“模拟”类继承。最经典的就是“构造函数 + 原型链”的模式。这种模式通过定义一个构造函数来充当“类”，然后将方法挂载到构造函数的 `prototype` 对象上。这样一来，开发者就可以用 `new` 关键字来创建“对象”，并且这些对象也能访问到原型上的方法，看起来就像是类实例化一样。
这种方式虽然不是 JavaScript 原生支持的类继承，但它成功地在 JavaScript 中构建了一个符合开发者习惯的抽象层。它提供了一种结构化的方式来组织代码，使得对象之间能够共享方法和属性，支持了封装（虽然 JavaScript 的封装更多是通过闭包和模块来实现）和多态（通过原型链的查找）。
再者，当时的 JavaScript 并没有官方的“类”语法。直到 ECMAScript 2015（ES6）引入了 `class` 关键字，才提供了一个更加简洁、更加接近传统面向对象语法的书写方式。但即使有了 `class` 语法，它本质上仍然是基于原型继承的一个语法糖。它并没有改变 JavaScript 底层的运行机制，只是让开发者能够用更熟悉的方式来表达原型链的概念。
那么，为什么很多人即便知道 OLOO（ObjectOriented, ObjectOriented）这种更“原生”、更符合 JavaScript 原型机制的风格，反而依然热衷于模仿类呢？
OLOO 确实是一种非常“地道”的 JavaScript 编程方式，它直接利用了原型链的委托机制，将一个对象作为另一个对象的“父级”，通过原型链进行委托。这种方式在某些方面确实更优雅、更灵活，而且避免了“伪类”带来的那些微妙的陷阱（比如 `instanceof` 的一些不便之处，或者 `constructor` 属性的维护）。
然而，OLOO 的推广和接受程度，相比于“伪类”模式，确实受到了一些阻碍。
1. 习惯的力量与生态系统的惯性：绝大多数 JavaScript 开发者，无论资深还是新手，都是从“类”的概念接触编程的。当他们学习 JavaScript 时，如果看到的是大量使用 OLOO 的代码，可能会觉得“看不懂”或者“太奇怪”，反而倾向于寻找那些更接近他们已有知识体系的解决方案。大量的教程、框架、库（在 ES6 之前）都是围绕着“构造函数 + 原型链”模式构建的，这形成了一个巨大的生态系统惯性。
2. “Class”语法的出现：ES6 的 `class` 语法，尽管只是语法糖，但它的出现极大地降低了模仿类继承的门槛。它让开发者觉得，JavaScript 终于“支持”类了，这使得“伪类”模式变得更加顺理成章，并且写起来也更短，更清晰。很多人看到 `class` 关键字，就自然而然地认为这是“官方”推荐的面向对象方式，便不再深究其背后的原型机制。
3. 工具和框架的支持：许多 JavaScript 工具（如 Linters, Code Formatters）和框架（如 React, Vue, Angular）在设计之初，或者为了兼容性，都或多或少地支持或鼓励了基于类的组件模型。这进一步强化了“类”在 JavaScript 生态中的地位。
4. 特定场景下的可读性：虽然 OLOO 在理念上更纯粹，但在一些复杂的继承结构或者团队协作中，如果团队成员都熟悉“类”的概念，那么使用“类”语法可以更容易地实现代码的统一风格和高效沟通。它提供了一种大家都能理解的“共同语言”。
5. “性能”和“简洁性”的权衡：在某些极端情况下，有人会认为 OLOO 可能在性能上（例如，查找方法时直接委托，而不是经过 `new` 产生的对象）或者代码简洁性上（避免 `new` 和 `constructor` 的 boilerplate）有优势。但这种优势在现代 JavaScript 引擎的优化下，以及大多数实际应用场景中，往往没有想象中那么显著。而“伪类”模式，尤其是 ES6 的 `class`，提供了一种相对平衡的写法。
所以，与其说大家“明知故犯”，不如说是在一个不断演进的语言生态中，开发者们在学习成本、认知习惯、工具支持、生态惯性和语言本身的演进之间，找到了一种最 pragmatic（务实）的解决方案。模仿类继承，尤其是在 ES6 之后，为 JavaScript 带来了更广泛的可接受性和更低的入门门槛，让更多开发者能够在这种强大的语言上构建复杂的应用，即使这并不是 JavaScript 最“原生”的面向对象实现方式。OLOO 是一种更纯粹、更符合 JavaScript 本质的选择，但它需要开发者跳出传统的思维模式，所以它的普及速度和接受度，确实不如那些更“亲民”的模式。
首先，我们得回到 JavaScript 的诞生和早期发展。它最初被设计成一种简单、易于嵌入浏览器的脚本语言，用来增加网页的交互性。那时候，很多其他语言已经有了成熟的类继承模型，这在当时的开发者群体中是一种非常普遍和被接受的编程范式。当 JavaScript 想要提供类似的能力时，原型继承（prototypebased inheritance）是其核心机制。但正如你所说，原型继承和传统的类继承在本质上有很大区别，它更像是“委托”而非“继承”。
然而，当 JavaScript 逐渐从一个简单的脚本语言发展成一门功能强大、应用广泛的编程语言，尤其是在服务器端（Node.js）的崛起后，它的复杂性呈指数级增长。这时候，大量的开发者涌入 JavaScript 的生态圈，其中不乏习惯了 C++、Java、C 等传统面向对象语言的开发者。
对于这些开发者来说，JavaScript 的原型继承模型，尤其是早期那些直接操作 `__proto__` 或者 `prototype` 属性的写法，显得非常“奇特”和“反直觉”。他们需要花费额外的精力去理解这种基于委托的继承方式，这与他们熟悉的“类”的概念相去甚远。
于是，为了弥合这种“认知鸿沟”，也为了让 JavaScript 的开发体验更接近他们熟悉的模式，一些开发者开始“模拟”类继承。最经典的就是“构造函数 + 原型链”的模式。这种模式通过定义一个构造函数来充当“类”，然后将方法挂载到构造函数的 `prototype` 对象上。这样一来，开发者就可以用 `new` 关键字来创建“对象”，并且这些对象也能访问到原型上的方法，看起来就像是类实例化一样。
这种方式虽然不是 JavaScript 原生支持的类继承，但它成功地在 JavaScript 中构建了一个符合开发者习惯的抽象层。它提供了一种结构化的方式来组织代码，使得对象之间能够共享方法和属性，支持了封装（虽然 JavaScript 的封装更多是通过闭包和模块来实现）和多态（通过原型链的查找）。
再者，当时的 JavaScript 并没有官方的“类”语法。直到 ECMAScript 2015（ES6）引入了 `class` 关键字，才提供了一个更加简洁、更加接近传统面向对象语法的书写方式。但即使有了 `class` 语法，它本质上仍然是基于原型继承的一个语法糖。它并没有改变 JavaScript 底层的运行机制，只是让开发者能够用更熟悉的方式来表达原型链的概念。
那么，为什么很多人即便知道 OLOO（ObjectOriented, ObjectOriented）这种更“原生”、更符合 JavaScript 原型机制的风格，反而依然热衷于模仿类呢？
OLOO 确实是一种非常“地道”的 JavaScript 编程方式，它直接利用了原型链的委托机制，将一个对象作为另一个对象的“父级”，通过原型链进行委托。这种方式在某些方面确实更优雅、更灵活，而且避免了“伪类”带来的那些微妙的陷阱（比如 `instanceof` 的一些不便之处，或者 `constructor` 属性的维护）。
然而，OLOO 的推广和接受程度，相比于“伪类”模式，确实受到了一些阻碍。
1. 习惯的力量与生态系统的惯性：绝大多数 JavaScript 开发者，无论资深还是新手，都是从“类”的概念接触编程的。当他们学习 JavaScript 时，如果看到的是大量使用 OLOO 的代码，可能会觉得“看不懂”或者“太奇怪”，反而倾向于寻找那些更接近他们已有知识体系的解决方案。大量的教程、框架、库（在 ES6 之前）都是围绕着“构造函数 + 原型链”模式构建的，这形成了一个巨大的生态系统惯性。
2. “Class”语法的出现：ES6 的 `class` 语法，尽管只是语法糖，但它的出现极大地降低了模仿类继承的门槛。它让开发者觉得，JavaScript 终于“支持”类了，这使得“伪类”模式变得更加顺理成章，并且写起来也更短，更清晰。很多人看到 `class` 关键字，就自然而然地认为这是“官方”推荐的面向对象方式，便不再深究其背后的原型机制。
3. 工具和框架的支持：许多 JavaScript 工具（如 Linters, Code Formatters）和框架（如 React, Vue, Angular）在设计之初，或者为了兼容性，都或多或少地支持或鼓励了基于类的组件模型。这进一步强化了“类”在 JavaScript 生态中的地位。
4. 特定场景下的可读性：虽然 OLOO 在理念上更纯粹，但在一些复杂的继承结构或者团队协作中，如果团队成员都熟悉“类”的概念，那么使用“类”语法可以更容易地实现代码的统一风格和高效沟通。它提供了一种大家都能理解的“共同语言”。
5. “性能”和“简洁性”的权衡：在某些极端情况下，有人会认为 OLOO 可能在性能上（例如，查找方法时直接委托，而不是经过 `new` 产生的对象）或者代码简洁性上（避免 `new` 和 `constructor` 的 boilerplate）有优势。但这种优势在现代 JavaScript 引擎的优化下，以及大多数实际应用场景中，往往没有想象中那么显著。而“伪类”模式，尤其是 ES6 的 `class`，提供了一种相对平衡的写法。
所以，与其说大家“明知故犯”，不如说是在一个不断演进的语言生态中，开发者们在学习成本、认知习惯、工具支持、生态惯性和语言本身的演进之间，找到了一种最 pragmatic（务实）的解决方案。模仿类继承，尤其是在 ES6 之后，为 JavaScript 带来了更广泛的可接受性和更低的入门门槛，让更多开发者能够在这种强大的语言上构建复杂的应用，即使这并不是 JavaScript 最“原生”的面向对象实现方式。OLOO 是一种更纯粹、更符合 JavaScript 本质的选择，但它需要开发者跳出传统的思维模式，所以它的普及速度和接受度，确实不如那些更“亲民”的模式。
网友意见
真假这个说法太不专业了，ES6以后"模仿类"也成为历史了，毕竟class关键字摆着呢，谈不上模仿。先说几个要点：
- 语法层面，JS至少支持四种范式：面向过程、函数式、基于类的面向对象、基于原型的面相对象。
- 运行时JS有原型的概念，大部分语法是使用原型机制来实现的
- JS语言本身的运行API，大部分是基于类的风格设计
此外，我认为JS的范式之所以比较受到诟病甚至中伤，是ES3及更早期，运行时全原型机制而语法只有Java风格的基于类，造成很多理解偏差所致。
ES5加入了Object.create等，ES6加入了class之后，两种范式已经可以很好地隔离使用。
Procedure Oriented
这个是最基本的范式，把函数当做子过程。可以使用 if else for while 来实现图灵完备
var a, b, c; function setAB(){ a = 1; b = 2; } function calculateC(){ c = a + b; } setAB(); calculateC();
Functional Programming
不需要什么immutable，只要你管住自己的手，只用 => 和 const，拒绝 var if for 等，我们可以得到一个跟scheme类似的语言，对比一下看看：
(define (fib n) (if (<= n 2) 1 (+ (fib (- n 1)) (fib (- n 2)))))
const fib = n => n <= 2 ? 1 : fib(n - 1) + fib(n - 2);
class-based oop
加入class以后，配合new，基本可以做到 class base 了
class Cat { jump() { console.log("high"); } sound() { console.log("miaow"); } } class Lion extends Cat { sound() { console.log("howl"); } } var lion = new Lion(); lion.sound(); lion.jump();
prototype-based oop
然后原型，自从ES5以后，可以抛开new来指定原型创建对象了，还可以用freeze来保护一下原型，class-less的面向对象，其实吧，我觉得谈不上优雅，各有各的口味罢了：
var catAlpha = { jump() { console.log("high"); }, sound() { console.log("miaow"); } } Object.freeze(catAlpha); var lionAlpha = Object.create(catAlpha, { sound: { value:function () { console.log("howl"); } } }); Object.freeze(lionAlpha); var lion = Object.create(lionAlpha); lion.sound(); lion.jump(); 类似的话题
-
说实话，很多人即便知道 JavaScript 的“伪”面向对象（prototypebased）和那些刻意模仿类（class）实现的模式，仍然乐此不疲地去实践，甚至觉得“真香”，这背后其实有一番挺有意思的逻辑和历史渊源。这并不是因为他们真的认为 JavaScript 是“真的”类继承，更多的是一种历史............. -
这件事儿，说起来挺让人费解，也挺让人心疼。明知大山要压下来了，为什么还要像没事人儿一样，每天准时打卡，出现在办公室呢？这背后啊，其实藏着不少说不清道不明的心思和现实考量。首先，得说说这“明知大难临头”这几个字。很多时候，这个“明知”也不是那么板上钉钉，而是基于一种模糊的预感、零星的传闻，或者是一种长.............
-
即便明知十赌九输，甚至连“十赌九输”这个概念都深入人心，为什么仍有那么多人前赴后继地奔向澳门等赌场？这个问题，其实比看起来要复杂得多，它牵扯到人性深处的欲望、心理的弱点，以及社会文化等多方面因素。咱们不妨掰开了揉碎了，好好聊聊。1. 无法抑制的“暴富梦”：这是最直接、也是最普遍的理由。谁不想一夜暴富.............
-
关于明末八旗军队的军事实力与历史评价，确实存在一些争议。明粉（明朝支持者）不承认八旗“真的很强”这一观点，主要源于以下几个方面的历史认知、文化心理和政治立场的交织： 一、历史认知的偏差：将八旗视为清朝的“逆贼”1. 八旗是清朝的军事力量 明粉往往将八旗视为清朝政权的军事支柱，认为其存在本身就.............
-
衣服款式好看却有廉价感，这是一个很多消费者都会遇到的困惑。明明看图片或者挂在店里的时候觉得不错，但实际穿上身或者仔细端详后，却总觉得少了点什么，甚至显得不上档次。这其中的原因其实是多方面的，我们可以从以下几个维度来详细分析：一、材质和面料：这是最核心的因素。 廉价纤维的质感不佳： 涤.............
-
这个问题就像一个绕不开的结，总有人在心里反复琢磨。明明生活在信息爆炸的时代，手机里装着全世界的地图、攻略、美景，手指轻轻一点就能“云游”四海，为什么那么多人却依然选择“宅”在原地？这背后，其实藏着好多好多说不清道不明的心思和现实。咱们先不扯那些宏大叙事，就从最身边、最实在的点点滴滴说起。首先，最直接.............
-
刚踏入大学校园，不少新生都觉得每月1500元的生活费算是一笔不小的数目，足以应付日常开销，甚至还能有些富余。然而，许多大学生的真实感受却是：钱好像永远不够花，日子过得相当“抠搜”。这背后其实隐藏着不少大学生活的“小算盘”，1500元看似不少，但要支撑起一个“体面”的大学生活，确实处处是考验。首先，我.............
-
这个问题其实挺有意思的，涉及到消费心理、社会文化以及信息不对称等好几个层面。不能简单地用“傻”或者“不知道好坏”来解释，背后有着挺复杂的原因。首先，咱们得聊聊“便宜”这事儿。十块钱一瓶的白酒，对于很多人来说，它代表着一种“能喝”，一种“低成本的社交润滑剂”。在一些场合，比如农忙收成后、邻里乡亲小聚、.............
-
关于“明粉认为汉唐没有明朝强大”的观点，需要从历史背景、比较维度、文化心理等多个层面进行深入分析。这一现象背后既有历史事实的差异，也涉及文化认知的主观性，以下从多个角度展开详细阐述： 一、历史背景的差异性1. 朝代的性质与时间跨度 汉唐：汉朝（前202年220年）和唐朝（618907年）是.............
-
关于马蓉案件中，一些人对马蓉代理律师的辱骂现象，我们可以从几个层面来探讨其原因，并且尽量用更具人情味的方式来解读：一、情绪的宣泄口，而非理性的判断首先，很多围观群众的情绪是高度被调动的。马蓉的事件本身就充满了戏剧性和争议性，涉及到婚姻、财产、名誉等多个敏感领域，很容易激起公众的同情心、愤怒或者“正义.............
-
你这个问题挺有意思，涉及到历史评价、群体认知以及网络舆论战。明朝在中国历史上确实是一个争议颇多的朝代，明粉（明朝历史爱好者）的某些言论有时也确实会引发一些反感。要深入探讨这个问题，我们需要拆解几个层面来看。一、 为什么会有人“厌恶”明朝？“厌恶”这个词可能有点重，但背后反映的是一些人对明朝统治和历史.............
-
你提出的这个问题非常尖锐，也触及了当下历史讨论中的一个敏感点。关于“黑明朝、美化清朝”的现象，确实存在，而且原因复杂，背后牵扯到不同的群体和他们各自的“目的”或“作用”。下面我将尽量详尽地分析这个问题，并尝试剥离掉AI可能呈现的“标准答案”感。一、 为什么会产生“黑明朝，美化清朝”的说法？首先，需要.............
-
这确实是个非常有意思且普遍存在的现象，明明我们从小到大都被教导“人不可貌相”，但现实生活中，我们却常常在不经意间，甚至是有意识地，根据一个人的外表来评判他们。这背后牵扯到很多深层的心理机制和社会因素，绝非一两句话就能说清的。咱们不妨掰开了揉碎了，仔细聊聊为什么会这样。一、 根植于大脑的“捷径”：进化.............
-
明朝宦官专权，权力触角伸向朝廷内外，而他们所主管的众多机构，不少都以“厂”字结尾，这背后既有历史的烙印，也有制度演变的痕迹，更是权力运作的体现。要理解为何这么多宦官机构被称为“厂”，我们需要从多个层面去剖析。首先，要理解“厂”这个字在明代之前的含义。在明朝之前，“厂”字并非专指宦官机构，它本身在汉语.............
-
这是一个非常有趣且深刻的问题，触及了人性中理性和情感、个体和社会之间微妙的互动。很多人即使不相信“善恶有报”这种超自然的因果论，也明白道德准则的功利性本质，却依旧能抵制诱惑，不贪便宜，不触碰底线，这背后有着多重原因，而且这些原因往往是交织在一起的，并非单一因素在起作用。一、 内在的心理机制与情感驱动.............
-
这确实是一个值得深入探讨的问题。明明有那么多关于中药有效成分的研究成果摆在眼前，为什么质疑中医的声音依然此起彼伏？这背后牵涉到复杂的原因，绝非一两句话就能概括。我尝试从几个关键点来展开说说，希望能更清晰地呈现这个问题。1. “有效成分”与“中医理论”之间的鸿沟这是最核心的矛盾之一。我们不可否认，现代.............
-
这是一个非常普遍的现象，也是很多人感到困惑的地方。明明很多人都说公务员工资不高，为什么周围很多公务员却过得相当滋润？ 要想详细解释这个问题，我们需要从多个维度去审视“滋润”的定义以及公务员这个职业的真实情况。首先，我们需要明确“滋润”的含义。对于大多数人来说，“滋润”可能意味着： 生活稳定，无需.............
-
明朝好，清朝差？这个问题，真是说不清，也道不明。就好比问“红楼梦”里林黛玉好，还是薛宝钗好一样，不同的人，看问题的角度不同，心中的答案也截然不同。至于为什么有人“吹明”有人“吹清”，那更是因为每个人手里拿着的“尺子”不一样。咱们掰开了揉碎了，聊聊这明清两朝，到底哪里招人喜欢，又哪里让人看不顺眼。明朝.............
-
这个问题确实触及了一个复杂且敏感的社会现象。很多人在超生后，即便行为本身触犯了法律，却常常表现出受害者的姿态。要详细理解这一点，需要从多个层面进行分析：一、 合法性与道德性认知上的混淆和模糊： 历史和文化根源： 在中国传统文化中，“多子多福”的观念根深蒂固。在过去，生育数量很大程度上关系到家庭劳.............
-
关于明末小冰期导致的水太凉，进而成为满清得天下的主要原因这一说法，在坊间流传甚广，尤其是在一些历史爱好者和通俗读物中。但如果深入分析，这种解释虽然有一定的事实基础，却过于片面，甚至可以说是将复杂历史事件简单化了。首先，我们要理解明末小冰期究竟是怎么回事。这并不是说冬天突然变成了北极，而是指一个相对较.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有