TypeScript中的私有属性
我们知道,TypeScript 是⽆法直接运⾏在浏览器中的,也⽆法直接运⾏在 nodejs 中。必须先编译成 js 以后才能运⾏在这些环境中。
当然这也不是绝对的,去年 nodejs 之⽗⼜新开了个坑——,能够直接运⾏ TypeScript。
之前因为觉得反正 TypeScript 最终是会编译成 js 运⾏在浏览器中或者 nodejs 环境中,那么是否 TypeScript 中所有的特性,都能在 js 中到对应的书写⽅式呢?
之前看⼀些 TypeScript 中类型的实现,感觉蛮有意思的,特别是对⽐ TypeScript 源码和编译后的 js 代码:
⽐如 typeScript 中的枚举:
enum Color {
Red = 1,
Green,
Blue
}
let c: Color = Color.Green;
编译以后的 js 代码:
var Color;
(function(Color){
Color[Color["Red"]=1]="Red";
Color[Color["Green"]=2]="Green";
Color[Color["Blue"]=3]="Blue";
})(Color ||(Color ={}));
var c = Color.Green;
⽐如以前从没觉得,原来 js 可以这么玩,创建⼀个对象,对象⾥⾯的 key、value 可以互相映射,通过 key 可以到 value,通过 value 也可以到 key。当然这⾥⾯,你得把 key、value 理解成⼀类数据的代称,⽐如例⼦中得颜⾊和数值。
⽽且,从这个编译以后得 js 代码中,我学到了⼀个很有意思的技巧,原来对于对象的属性进⾏赋值的时候,执⾏完赋值语句以后,是有返回值的。
不过结合对象的 get\set 属性想想,就应该知道这个道理并不难理解了。
赋值,同样是调⽤了⼀个⽅法,最后给个返回值,这个返回值刚好是就是传⼊的值,以显⽰赋值成功,这个设计理念很好理解,也很符合逻辑。
当这个概念⽤久了,我就想当然的以为,TypeScript 中的代码应该所有的都能编译成对应的 JavaScript 代码,并且也应该是符合逻辑的。
但是直到我碰见了类中的私有属性,才颠覆了我这个惯性认知。
我们知道的是,Javascript 的类中是没有私有属性的,如果想模拟私有属性的话,必须要⽤闭包来模拟。
⽐如下⾯这段 TypeScript 代码
class Animal {
private name: string;
constructor(theName: string) {
this.name = theName;
}
private sayName(): string {
return this.name;
}
}
我本以为编译成 JavaScript 会是这样的:
var Animal =/** @class */(function(){
var name;
function Animal(theName){
name = theName;
javascript的特性}
Animal.prototype.sayName=function(){
return name;
};
return Animal;
}());
如果编译以后,代码是像我预料的这样的话,那么这个地⽅的私有属性也就合情合理了,毕竟我在这个类的外部是完全⽆法访问到这个属性的,只在定义这个类的作⽤域内部才能访问到。
但是实际上,我⽤最新的 TypeScript 3.1 版本编译上述代码以后,结果是这样的:
var Animal =/** @class */(function(){
function Animal(theName){
this.name = theName;
}
Animal.prototype.sayName=function(){
return this.name;
};
return Animal;
}());
这个结果刚开始让我很难理解,这样定义构造函数,这个 name 怎么能算上是私有属性呢?
这个问题我纠结了很久,苦思不得其解。
知道我看到了 deno,我才想明⽩,其中的缘由。
我们知道,TypeScript 是 JavaScript 的超集,那么就说明,TypeScript 中的概念不⼀定在 JavaScript 中存在,但是反过来是肯定的。
明⽩了这⼀点,就不难理解其缘由了。
TypeScript 解决了 JavaScript 中的⼀些痛点,没有类型约束、浏览器⽀持滞后等等。但是这不意味着,TypeScript 就等同于JavaScript 了。如果两者完全等同,何必要花费这么⼤⼒⽓造⼀个新的轮⼦呢?
TypeScript 编译成 JavaScript 后的代码,如果你混合着别的 JavaScript 源码来⽤,照样是缺乏安全性保障的。但是它安全性体现在,我们如果全部是⽤ TypeScript 来写我们的项⽬,编译器会负责把我们 TypeScript 源码编译成能正确运⾏的 JavaScript 代码,并且⾄少有99.99% 的概率能够确保在运⾏期间不会出错。
这不由得让我联想到,机器码和⾼级编程语⾔之间的关系。既然所有的编程语⾔都需要编译成机器码才能跑在计算机上,那么为什么我们说JavaScript 写的代码安全性太差,⽽ Java 写出来的代码安全性更好,更适⽤于⼤型的⼯程呢?
究其原因,⼤概就是因为,不同语⾔对使⽤者的要求是不尽相同的吧。深谙 JavaScript 的⽼⼿,写出来的代码,我不相信会⽐⼀个 Java 新⼿写出来的代码可靠性要差。
如果把 JavaScript ⽐作是⼀把砍⼑,那么 Java 就是⼀把⼔⾸。
砍⼑看起来威风⼋⾯,作战半径很⼤,只要是个⼒⽓⼤的⼈,拿起来就敢上战场砍⼈。但是⼔⾸呢,很多⼈拿着就很发怵了,这玩意这么短,拿着砍⼈不是送⼈头么。
砍⼑虽好⽤,但是想⽤好却难,⽤来有效的杀敌更难;⼔⾸虽然难习,但是⼀旦习成,近战⾁搏,杀⼈效率堪称恐怖如斯。

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。