为什么面向对象分析与设计的能力这么不受重视

这里人真多啊

@yegle 总结的很到位

@lch21 参见51楼我的回复，我的算法基础比别人比不上，比你还是绰绰有余的，因为你语文水平不行

= =！ 被问到设计模式一概答不知道不懂

@wog 吐槽面向对象设计和设计模式的 http://coolshell.cn/articles/8745.html 哈哈

算法和数据结构是基础，没有这些技能，谈设计模式和软件架构就是空中楼阁

看需求，算法和数据结构我只是略懂。程序员是工程师，不是数学家或者科学家。

有一种感觉，越是问算法的面试官，实际项目经验越弱，因为真正做过项目的人会拿项目中遇到的问题来提问，而不是书上的XX排序。

因为这些垃圾公司管面试的喜欢学google，但是他们这群sb也不看看自己公司有没有google那种要求。

因为这种能力的建立于大量的实践经验，而且对architect的需要不是很多，有那么几个就够了，而且要求也非常高。数量上需求更多的还是coder吧

@firsthym can't agree more

设计模式以及面向对象坑人无数。这些东西太抽象，没有大量实践经验空懂理论只是纸上谈兵。相比之下，算法和底层机制的考察更加实际一些。

面向对象和设计模式不是一回事吧？
我觉得这些更多是积累而来的经验而不是单纯可以靠看一本什么设计模式的书来获得的能力
而且我认为设计模式给新手带来的误导往往大于实际的效果

@RisingV 比如，C++ STL已经实现了很多优美的排序算法，作为实践家的程序员来说，为什么非要理解sort()背后的故事？

@ipconfiger 我正想贴这个链接呢

@bhuztez 你好像搞混了OO和Actor Model，虽然二者真的很像。

OO跟Actor Model解决的问题不同。OO是一种编程范式、软件工程的方法论，通过对数据和操作的封装提高代码复用性。Actor Model是一种计算模型，解决并发和分布式计算问题。

虽然Alan Kay在采访中提到Actor Model近似与OO中最好的那部分精华，可OO不是Actor Model。Smalltalk和OO概念不是为了解决并发而提出的，而是图形界面革命的产物。

@Alex_L 真正的OO和Actor Model不完全是同一个东西，但大致上是一样的

OO提出来的时候，Alan Kay说的是，一个程序就相当于有很多mini computer同时在运行，他们之间通过消息相互通信，就好像以太网里的多台computer相互通信一样。他只是受Simula 67启发，有这么个思路而已。他还没去实现呢，到底怎么实现，还没定论呢。所以，才有了后面一系列Smalltalk语言。Smalltalk不是一种语言，Smalltalk是一系列语言。Smalltalk 72和Smalltalk 76完全是两种语言，虽然他们都叫Smalltalk。

Actor Model是Carl Hewitt把这类想法整理出来写了个形式化的定义，并且加入了capability。

等后来OO变成了buzzword，于是几乎所有人都不得不搞混了。假如你的语言不号称支持OO，连你自己都会觉得低人一等的。这要怪也得怪Alan Kay他们，他们后来公开的Smalltalk 80和OO真是一点关系都没有。

所谓对数据和操作的封装，根本就什么都不是。从Lisp角度看，这只不过是把(method x y)变成了x.method(y)。这种语法糖甚至在很多时候会降低代码复用。本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。从Erlang的角度看，这就是一个Poor man's pattern matching，只能匹配类型，Erlang的作者们根本不屑于承认他们实现了OO。你再想想，Design Pattern那本书完整叫啥："Design Patterns: Elements of Reusable Object-Oriented Software"。

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

图形界面革命是T-Square和Sketchpad。之前也有图形界面，但是真正向大家展示怎么样写一个图形界面能用来辅助完成工作的，就是这两个了。就相当于是1962年的鼠标，和1963年的平板了。Xerox PARC开始了PC革命，Smalltalk确实一种是为了把PC从军方的实验室里的各种GUI玩具带给广大屌丝们而设计的语言。GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。你再想一想，Emacs里面就是各种Event-driven了，Tcl/Tk也是。node.js只是最近的hype而已。

http://en.wikipedia.org/wiki/T-Square_%28software%29
http://en.wikipedia.org/wiki/Sketchpad


这就是一个著名的anti pattern，想把在一种场景下有效的方法当成golden hammer推广到所有领域的时候。那个buzzword OO可以算是一个，event driven则是另外一个。

http://en.wikipedia.org/wiki/Golden_hammer

Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。根本达不到什么编程范式、软件工程的方法论这么的高度。

考算法是没有问题的，问题在于直接考算法的背诵有很大问题。哪有直接考默写快排的，这样的题目根本没有区分度。
说白了还是要寻找有解决实际问题的能力的人，默写个快排就有能力了么

@bhuztez

“OO提出来的时候...并且加入了capability。”
这些都没问题，我们的理解一致。

你批评OO的封装降低代码复用：“本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。”
我不是太理解这句话的意思，能举个栗子讲一下吗？我的理解是像迭代器这种东西可以用于多种类型，也不需要在每种类型里重定义啊。如果一个method能用于多种类型，必然能通过组合、继承等手段抽象出来；如果一个method需要在多种类型里定义，必然不能适用于多种类型，不关OO事。OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

“GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。”
输入框这个例子跟并发有什么关系？GUI里并发多在哪里？

“Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。”
模式匹配什么时候成OO标配了？语言级的抢占式调度跟OO有关系吗？你对"true OO"的理解还是解决并发问题。Alan Kay设计OO的动机：“Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.”真的不是并发。OO跟Actor Model的关系是为解决不同问题用到了共同的思想。

编程范式就是人写程序的方式，方法论的潜台词是你不这么干也能出活，真心没到什么高度，至少不是你想的那种高度。

@bhuztez 插句闲聊，你对Erlang的狂热让人印象深刻。

@Alex_L

> OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

就是啊，现在大部分号称支持OO的语言就是有病啊，连Integer都要包一堆方法进去啊。再来展示他们高级的boxing/unboxing的技巧。Immutable的量都有方法明显就是病得不轻了啊。

GUI里并发天然多啊。并发是什么？并发就是有很多状态在同时变化，这些状态还相互关联，一个变了，还能引起很多其他状态变化。就类似Alan Kay的那个mini computer metaphor。就刚才说的spreadsheet，每个格子都有一个值，那就是它的当前状态，接着你去改变一个格子值的时候，别的格子如果定义了公式用到了这个格子的值，那也会相应变化，那就是改变了他们的状态，那就是大量并发啊。


> The large scale one was to find a better module scheme for complex systems involving hiding of details

Message Passing就是为了解决这个问题啊。你并不关心另外一个process内部状态是怎么变的，你把他当成一个黑盒，你发个消息过去就好了。那些把各种方法绑到类型里的语言，就是在意淫调用了一下这个方法就是把这个消息发过去了，结果另外一个object挂了，抛了个错，你也得跟着挂了，这也算封装？只有实现真正的消息机制，才算是封装。消息机制的原型就是Simula 67。OO和传统的过程式语言在概念上有啥区别，过程式语言只有一个过程在顺序执行，OO是有多个过程同时或者交替在执行。

> the small scale one was to find a more flexible version of assignment

Pattern Matching就是为了解决这个问题啊。你是希望写

{ok, Result} = do_something()

还是

errno, result = do_something()
if errno:
raise MyException

还是

try:
result = do_something()
except SomeUnexpectedError:
raise MyException


如果你去翻翻各种邮件列表，肯定会发现Alan Kay提到过最早的那个Smalltalk就是Pattern Matching + Message Passing。

最后，不得不引用一句

Erlang is Smalltalk as Alan Kay wanted it
- Niall Dalton