请停止将 JavaScript 类型化（建议不要使用 class 实现类继承)

JavaScript

继承

class

49 条回复 • 2024-01-16 09:35:09 +08:00

1

phoenixlzx

2015-07-27 11:17:49 +08:00 via Android

卷写 js还没用过 class 来着

2

FrankFang128

2015-07-27 11:19:29 +08:00

我实名拒绝在 JavaScript 里使用 class

3

yakczh

2015-07-27 11:32:11 +08:00

原型挺好的,需要什么功能就动态加上就行了, 如果按java那样搞,需要动态功能了,那得在内存中修改字节码

4

tushiner

2015-07-27 11:43:18 +08:00

1

妄图给js强加传统oo特性的都是不懂装懂之人

5

ffffwh

2015-07-27 11:44:31 +08:00

@yakczh
为了性能

6

magicyu1986

2015-07-27 11:45:15 +08:00

class属于有的没的东西，有了更好，没了也将就（好吧，每个人都写过一个拷贝式继承函数对吧）。
给一个正儿八经的int跟byte才是王道。看着用64位浮点模拟byte好可怜。

7

YuJianrong

2015-07-27 11:49:27 +08:00

继承结构复杂的情况下用class style很好，很能解决问题。
说这种话的人我觉得是没经过大脑，去看看browser自己的实现，随便找一个：
HTMLDivElement -> HTMLElement -> Element -> Node -> EventTarget -> Object
这哪里是什么“清晰，整洁，也更符合语言”的原型方式啦……

项目复杂的话，用同样方式抽象不是非常合理的吗……

8

tabris17

2015-07-27 11:51:17 +08:00

@ffffwh JIT方法已经能很好地解决Javascript原型链访问的性能问题了

9

matsuijurina

2015-07-27 11:51:44 +08:00 via iPad

反正我用coffeescript

10

tushiner

2015-07-27 11:53:37 +08:00

@YuJianrong 楼主的意思是，不要将传统面向对象语言的class与js的prototype混为一谈，没有说不使用继承、封装等思想。

11

otakustay

2015-07-27 11:56:13 +08:00

1

这作者简直在扯谈

《停止将JavaScript类型化，不要使用class》
《停止将JavaScript函数化，不要使用function作为第一级对象》

然后JavaScript就消失了呗

而且论点站不住脚，因为一个东西可能被人误解，所以我们不要用它，这样的话社会永远没有进步

12

YuJianrong

2015-07-27 12:02:37 +08:00

@tushiner 仔细看看文章去：

我很清楚经典继承方式的吸引力。甚至道格拉斯Crockford， JavaScript Good Parts （原声PPT）作者都实现了一个经典的伪继承，开明的JavaScript的创造者布Brendan Eich似乎喜欢很ES6中的class。对于许多程序员来说，这是在他们使用JavaScript之前很熟悉和舒适的编程方式。然而，JavaScript并不是一个经典的语言，语法糖和ES6的新class关键字只是在自欺欺人。
...
...如果你想了解 class 这样的关键字为什么那么可怕，为什么原型继承比经典的好....

这还不是明说了不要搞继承要用原型吗……

13

learnshare

2015-07-27 12:05:29 +08:00

1

人生苦短，我用 TypeScript

14

tabris17

2015-07-27 12:06:05 +08:00

我觉得原型的最大弊端就是容易写出糟糕的代码，而且这种代码根本无法阅读和调试

15

tushiner

2015-07-27 12:07:23 +08:00

@YuJianrong ”使用原型“就是js版本的”继承“，继承是一种思想，而不是语法，与关键字、表达式结构无关。

16

tushiner

2015-07-27 12:11:41 +08:00

@tabris17 这点确实是的，只能靠不断积累的经验技巧来解决这些问题

17

ixiaohei

2015-07-27 12:18:55 +08:00

读不懂这文章讲的啥

18

Jex

2015-07-27 12:29:34 +08:00

2

前几天刚说过某些 JavaScript 程序员压根不懂 OOP 就在那瞎扯有的没的： http://www.zhihu.com/question/24076626/answer/55284360

怎么又来瞎扯个不停呢。
《请停止向 JavaScript 中添加 yield，用 callback 即可》
《请停止向 JavaScript 中添加 let，用闭包即可》
《请停止向汇编语言中添加 call 指令，用 push jump即可》
这就有点像CISC跟RISC之争一样，事实上只需要一个翻译器运行时将复杂指令再转换成精简指令就行。之所以要有程序语言就是为的抽象啊。

我在话题下面说过了，https://v2ex.com/t/201281 ，现实会来打他们的脸。

——
原来我曾经看过的GC测试是在你博客上看到的 @otakustay
http://otakustay.com/about-closure-and-gc/

19

tabris17

2015-07-27 12:38:11 +08:00

@tushiner 没有技巧的语言才是适合生产的语言

20

datou552211

2015-07-27 12:49:06 +08:00 via iPhone

@tabris17 只能说实现特定功能的语法糖太多了不好

21

Jex

2015-07-27 12:57:55 +08:00

@otakustay 感谢你的详细测试，我相信其中「多个嵌套函数」一例从原理上来讲是一个Bug，将来会被解决。另外有一个补充，Direct Eval Call 第二个要求是 GetValue的值必须是标准 built-in eval function，但这点JS解释器是无法静态推断的，所以JS解释器GC上认可的只有第一个要求，即名字是 eval的 Call Expression就行了。所以在非Strict ES5下，并不是「非直接eval」（也就是「间接 eval」，Global scope的eval）就一定可以被GC。

22

otakustay

2015-07-27 13:04:22 +08:00

@Jex 我当时认为“多函数嵌套”下如此粗暴的GC机制是为了整体性能上的衡量，也出于那个时代JavaScript为基础的大型应用/游戏并不流行的前提，现在是怎么样不大清楚了，好久没再测一下了

关于eval那段是没错，或者我这么理解：非严格模式下浏览器基于静态lexical分析对直接eval的判断不特别准，而GC机制并不与eval实际执行时的状态（直接/间接）关联，而是和静态分析关联

23

21paradox

2015-07-27 13:56:16 +08:00

不知道为啥这么多人讨厌coffeescript

24

Jex

2015-07-27 14:02:17 +08:00

@otakustay 是的，因为可能同样的代码`eval(code)`这次调用是Direct下次又变成Indirect了，所以原理上解释器无法作普适的优化。

25

fds

2015-07-27 14:11:10 +08:00

看到文章中说 “CoffeeScript就不一样，它是完全不同的。如果没有学过该语言，它会很难读懂” 就觉得没有继续看下去的必要了。coffee明明只是个语法糖，跟js是直译的。作者这点儿功力就不要阻挡潮流了。

26

YuJianrong

2015-07-27 14:20:31 +08:00

@tushiner 好吧确实原型继承也是继承。不过JS版的class实现说到底也是建立prototype chain的helper而已，实在感觉不到黑点……

27

MyLady

2015-07-27 15:00:15 +08:00

爱用用,不爱用就不用又没人强迫你...
如果没人觉得OOP好那Mootools早死了吧

28

realpg

2015-07-27 15:06:19 +08:00

@yakczh
总有一些JAVA程序员想把他接触过的什么非JAVA的比如JS比如PHP都改成java那样

29

secondwtq

2015-07-27 15:21:40 +08:00

@learnshare 握爪。

我认为 Coffee 的目的是将 JS Ruby 化，TypeScript 的目的是将 JS C# 化，两者都没有也不可能把这个事情做彻底。

我最近随便看了一个开发 HTML5 游戏的库 Phaser。该库的作者在 13 年 8 月发过一个贴子征集意见：

http://www.html5gamedevs.com/topic/1218-would-any-of-you-care-if-i-dropped-typescript-support-from-phaser/

在 15 年 4 月又发过一个贴子：

http://www.html5gamedevs.com/topic/13599-reconsidering-building-phaser-3-in-typescript/

两个贴子的回复中撕比成分较多，我都没有全部看完，但是可以根据记忆大概说一下内容。

Phaser 貌似原来是使用 TypeScript 构建的，然而随着工程不断展开，遇到了问题。那时候 TS 不很成熟，尤其是工具链，经常出现崩溃之类问题，作者忍无可忍，用 JavaScript 重写了整个库。但是并没有完全放弃 TS，官方依然维护着一套 .d.ts 文件。但是"things don't sit still for long in the web world"，现在 TypeScript 越来越成熟，作者在考虑换回去。实际上使用 JS 和使用 TS 都有各自的利弊，这个跑题太远按下不表。但之所以不使用 TS 是因为一些其他的实际问题，比如工具、编译环节、TS 自身的小众、community 贡献的限制甚至 M$ 之前的一贯德行等，确实有许多人承认，TypeScript 是构建游戏的优秀工具。作者说过他虽然不使用 TS 写库了，但是依然会用 TS 写自己的游戏。

TS 还有一个好处，就是向下兼容 JS，并且对 ES6 有支持，这是 CoffeeScript 貌似难以做到的。

30

learnshare

2015-07-27 15:56:08 +08:00

面向对象、继承都是编写复杂应用的重要条件，原型、class 的继承方式是两种不同的实现方式而已，没什么优劣。在 ES6 获得广泛支持之前，伪 ES6 的工具还是要编译成 ES5 的原型继承来用。
能烧火的就是好柴，不管是树墩还是牙签。