@loveyou1 外包公司来来去去就那几个，签合同就看得出了

@optional 我需不需要看场景啊，我觉得会有场景需要

Introduction to Algorithms, third edition

@Boeisolation 出门左转北师

@optional 不是不相信我的队友，就如#26 所说，一般都是写库和写 SDK 的需要。还有一种情况可能是跨团队。
封装就是暴露接口，隐藏实现。暴露和隐藏都是关键。暴露的接口可以认为是有保证的，一定会出现预期的（和文档描述一致的）结果。在这个基础上，所有隐藏的部分，无论是方法还是域都可以随便改随便重构。
hard private 的好处是可以保证你的 API 的使用者的程序一定不会因为你的重构，升级和优化等等而受到破坏。当然如果所有 API 的使用者都遵循 naming convention，这些 API 的使用者也可以受到封装带来的好处。
封装的主要受益人是 API 使用者，但是却是 API 的开发者来写的。如果库，SDK 的开发者根本不在乎他的用户的长期的使用体验，可以不用封装。
#22 说的情况是，过去很长时间里，前端的库不多，在浏览器运行的代码也不多，很多时候用户都是自己调自己的方法，这时候可能就是“跑起来就行”
还有一种情况是，很多程序在开始建项目的时候确定了一个版本，后来就没再升级过，这个时候就可以像#2 那样随便 hack

找个人要个 byr 的号上论坛问，这里估计没几个人能给靠谱答复的

@zixiCat 北邮刚刚做了院系调整，没有软件了

@seki 我想写的时候你就知道哪些是私有的啊，不是都有#开头？不去拿#开头的变量不就没问题了？

@no1xsyzy 有趣的解释
阅读 https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-is-encapsulation-a-goal-of-this-proposal
“While it's already possible to model true encapsulation using either per-instance closures or WeakMaps”
这里的 true encapsulation 是指什么？

@no1xsyzy 还真有人出来挑战
来说说什么是封装

#30 288ppi 的屏幕上的字会比 72ppi 的小很多
px 的好处是文字相对图片的大小固定，因为图片大小都是 px 。除了这方面的考虑，一般都不推荐 px

#15 应该是对的
ppi 你知道吧，就是 pixels per inch，每英尺多少个像素
如果用 px 的话，在同样大小的屏幕上，288ppi

另一个原因，我说得可能比较得罪人
就是很多前端工程师根本不懂什么叫封装，不懂什么叫 information hiding

https://github.com/tc39/proposal-class-fields
是个好东西，因为没有私有变量就没有真正意义上的封装。过去要有私有变量只能利用闭包。
不过目前还没正式进入标准，所以没有大项目敢用吧

1 菜
2 态度不行

#1 换成数组 v-for 也有可能

ajax 的一开始触发了一个 v-if 销毁，回调再生成

#16 手抖变成了回复……
另外主楼里的 handleCheck 和 handleClick 方法的一大区别是后面的等号
handleCheck = () => {}
这句实际上是 https://github.com/tc39/proposal-class-fields 的语法，因此方法是在对象上而不是在原型上，因此不需要在构造器里面再 bind handleCheck

另外主楼里的 handleCheck 和 handleClick 方法的一大区别是后面的等号
handleC