对我而言,面向对象程序设计只意味着
消息发送(messaging),状态处理的局部保存、
保护和隐藏(local retention and protection and hiding of state-process),
还有一切东西的极端迟绑定(extreme late-binding of all things)。
这些在Smalltalk和LISP中都可以实现。可能还有其他系统,但我不知道。
似乎认为Erlang“可能是唯一的面向对象语言。”
因为Erlang具备面向对象编程的三原则:基于消息传递机制,对象分离和多态。
有一点倒是, 随着搜索, "Actor 模型"这个词多次出现在视野当中了
http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442?pgno=3
Binstock: How do you view the Actor model?
Kay: The first Smalltalk was presented at MIT, and Carl Hewitt and his folks, a few months later, wrote the first Actor paper.
The difference between the two systems is that the Actor model retained more of what I thought were the good features of the object idea,
whereas at PARC, we used Smalltalk to invent personal computing.
It was actually a practical programming language as well as being interesting theoretically.
I don't think there were too many practical systems done in Actors back then.
我一直在学 JS, 多线程和并发没有清晰的概念, 对函数式和 OO 觉得理所当然 网上总是会有人发表的各种声音, 或许还相互冲突 最后只能凭自己松散的根基去搜索, 询问和想象
出于个人对语言的理解, 我期待语言是清晰易用的, 其次才是强大 最初从 Python 看 OO 觉得好复杂, 后来看基于原型的 OO, 才渐渐明白这里对象的概念 基于原型链的 OO 通过
__proto__
和.bind()
或者__index
和setmetatable()
改变搜索变量的方式 我相对喜欢原型链这种更直白的方式,另外不太消化地看了下面的文章...
还有 lich_ray 在博文里侃基于原型的 OO 和 lambda 的关系: http://lichray.iteye.com/blog/89241
我一般只是在 Node 和 jQuery 中享受 OO 带来的方便 以致我觉 OO 的好处更多在于有一个类似表的结构, 将操作绑定到了对应的数据上边 我在知乎上解释了问题, 但回答更让我觉得重点不在 OO 上.. http://www.zhihu.com/question/20405888 而且对于 OO 的态度, 我印象很深的说法是 http://www.zhihu.com/question/20275578
另外我在学习 MVC 框架时也积累这对于 OO 的困惑, 于是去知乎询问怎样才是纯粹的 OO, 结果反而没有完全信赖的回答 http://www.zhihu.com/question/20185591 这时自然想到去追溯更接近 Alan Kay 的一些说法来理解了 http://blog.csdn.net/turingbook/article/details/1873481
而且来自权威的一些大神的声音反而让我更为困惑 http://www.infoq.com/cn/news/2010/07/objects-smalltalk-erlang
因为我只是写 JS 的基础, 所以只好继续从网上检索 OO 的信息 关于 Actor 模型我找到了 JeffreyZhao 的博客, 很明白地, 那是关于并行的 http://blog.zhaojie.me/2009/05/a-simple-actor-model-implementation.html
也刚好 logickthing 给的关键词里我遇到一个打动甚至让我信服的说法: http://weibo.com/2701649502/yyigOxs4E
到这里就有真的很震撼我的信息出现了, 因为纯函数的就是为了解决并发 学 Haskell 我接看一些博文, 临时先找一篇说到的 http://blog.csdn.net/manyoo/article/details/5405252 编程语言因为不同线程共享状态, 同时修改发生冲突会出错, 因而出现了锁的概念 更高级的 Clojure 是用事务内存, 在少见的冲突时才回滚重新修改, 也是为这个 而函数式语言选择了不修改的状态, 有个 Erlang 和 Haskell, 平常写脚本我受不了纯函数, 后来这样明白这是为并行而设计的 当我看到 OO 最初也是面对同一个问题, 顿时有些吃惊
在 Node 的介绍里我慢慢有点明白上边的说法 http://www.ibm.com/developerworks/cn/web/1201_wangqf_nodejs/
似乎在别的文章我看到了, 因为数据只在一个线程中能够被访问和修改 那么不存在不同进程访问相同数据带来的冲突, 也就适用于并发 而 JS 本身就是单线程, 明显就不会有不同进程破坏数据一致性的问题 到这里关于 OO 我遇到的困惑总算能说清, (自然关于细节还要继续学...) 在很多框架里呈现的很整齐的对象封装, 那种对于 对象过度的信赖也可以解释
从我的角度, 大概不成熟, 的看法, 我觉得 OO 并未在我扮演多正要的角色 首先为了数据和操作排列有序, 我没需要的是 JSON 或者 Lua 中表的结构 有了表, 从另一模块引用的代码清晰地绑定在对应的变量上边, 操作数据的方法也类似 另外借助
__index
之类属性, 我们在需要时也能快速构造出此类结构 关于 OO, 我主要是不想遇到代码就出现class
之类强行设定我思路的结构 作为还不是码农, 我期待的是代码清晰地展示大脑思考和代码运行的结构, 而不是框架的积习在学 Node 过程中, 我花了相当长时间去适应带有 CPS 风格的回调 传统同步代码, 比如
ret = prompt()
会阻塞进程, 然后将返回值传给ret
在 Node 中fs.readFile('name', 'utf8', cb)
就只有undefined
这样的返回值了 进而, 我试想在消息的世界当中, 同步代码的返回值将不再常用 如果说一切写得极端了, 全部的颠覆.. 我只是觉得会比较有趣, 当然明显不实用然后我看到了 CoolShell 上关于线程模型的思考 http://coolshell.cn/articles/4626.html 还有徐昊写的"对象已死?"的文章, http://www.infoq.com/cn/articles/object-have-dead 开始期待着线程概念早日被更高级的抽象所取代