"算法+数据结构=程序"过时了吗？

captivated

就搭积木做个能用的东西什么的来说，
什么可扩展性，可维护性都TMD废话，搭出来能用不就行了？

搭积木搭成了一框架，这时才开始考虑可扩展性和可维护性。
而框架的核心，仍旧是数据结构加算法。

OO设计模式，大多是继承体系之间如何解耦的问题。而继承体系之间需要解耦正是语言OO的缺陷。
所以设计模式是用来解决OO的缺陷的，而不是说设计模式让OO有了什么优点。只是OO相较于过程式可能有一点儿优点。

OO不过是用来装核心数据结构和算法的，相较于过程式的另外一种容器。

考虑个问题，比如：OO能从根本上降低数据结构和算法的复杂性吗？

举个栗子。
一个类，有它的私有成员，有一系列操作成员的函数。
如果我写一个.c文件，放同样的这些成员，把这些成员都搞成全局变量，然后写同样的一系列函数。
那么这个.c文件和这个类唯一的差别，在于类具有了所谓的封装性，另外的类不能访问这个类的私有成员。
然后所谓的继承和多态，用一个.c文件代表一个类这种想法来做，可能就会麻烦些[其实不会有太多问题]。
OO的基本想法，相较于过程式的优点，可以通过这种方式来对比。
OO的思想也在于此 -- 龙生龙凤生凤老鼠生的儿子会打洞，这就是OO的思想。
所以OO唯一有点用处的就是这一点想法，重复来重复去，还是几个关键字：封装，继承，多态。这几个关键字大约是用来解决可扩展性和可维护性的 -- 它完全不能改写数据结构，该用什么数据结构，还用什么数据结构。数据结构和算法仍然在那里，不过从过程式中被放到了几个类中。

所以，数据结构是怎么样的，它仍然是怎么样的；算法是怎么样的，它仍然是怎么样的。区别之在于，放置它们的方式。数据结构和算法本身的复杂性完全没有减少。

可是OO的继承，多态什么的，说是为了可扩展性和维护性，但结果却是，很容易写一大堆不能扩展也不能维护的垃圾代码... 即这时OO本身出现了问题。它的扩展性和维护性和过程式一样的出现问题。
然后设计模式出现了，说如果要OO，应该这样写代码什么什么的 -- 这是为了解决OO的问题，而不是让OO有什么更多的优点。

总之 -- 数据结构和算法仍然是要的，而且它就是核心。

=====================

剩下的不掰了。码字累... 而且明天懒懒散散木有事情做，我好无聊，哈哈。

=====================

cienet917

2.  面向对象编程这公式同样适用

蔡万钊

pmerofc 发表于 2012-12-02 16:46
不同意这个说法

有理由么？

蔡万钊

库 = 数据结构+算法。

程序 = 库 + 设计。

设计为王。空有算法和数据结构也不能让你写出优雅的程序。

shan_ghost

OO是更加严格的 程序=算法+数据结构；或者说，它根本就是把相关的算法（成员方法）和数据结构（成员变量）显式捆绑起来了。

如此极端、呆板的“程序=算法+数据结构”思想，居然被人理解为OO就不需要“程序=算法+数据结构”了，让人情何以堪。
——说面向对象是极端、呆板的“程序=算法+数据结构”，是因为严格的面向对象语言压根就不允许算法和相关的数据结构分离：比如Java就不允许独立函数存在。

正是因为太多人不懂这个，甚至反而跑一边沾沾自喜的叠面向对象的乌龟塔，以为这下可算摆脱老掉牙的“程序=算法+数据结构”的束缚了，这才搞出很多怪异的垃圾，进而把面向对象闹的臭不可闻。

JohnBull

我觉得，现在似乎应该进化成：

算法+数据结构+数据呈现 = 程序

数据呈现包括人与程序之间、程序与程序之间的交互界面。

shan_ghost

OO的本质是什么？是那些聒噪的方法论吗？是那些class/inherit关键字吗？

当然不是。

OO本质上就是一个“里氏代换原则”：当程序中一组子模块达到足以满足里氏代换原则程度时，上层就可以忽略细节差异，以统一的模式操作所有这些子模块：这是面向对象的唯一目标和唯一好处——那二十多个设计模式，实质上不过是这个原则的变形或基于这个原则的推广罢了。


面向对象的三大原则：
封装——为什么要封装？因为当我要在诸多子类上应用“里氏代换”的时候，当然不能容忍你挖掘我的隐私。不然我还怎么作出可代换的抽象？
继承——为何要继承？因为既然我已经基于“里氏代换”做了一套体系，那么你就没必要再来搞一套类似的体系。改我让你改的。这就是继承。
多态——为何要多态？这根本就不该是个独立的问题。又想要继承，又想子类和父类的行为有所不同，不支持多态又能怎样？

————————————————————————————————
更深了说，面向对象三要素（乃至23个设计模式）实质就是为了一个“开闭原则”的支持而已。


所谓开，是对扩展开放；所谓闭，是对修改封闭。

对扩展开放，意思就是一个模块不能是僵死的，将来需求有变，它必须能够扩展以应对新的需求。

对修改封闭，意思就是：一旦一个模块设计完成，那么就不再允许（为了添加功能而）做任何修改。
换言之，代码写完了，那么原则上，除了修改bug，它就凝固了，一个字节都不能再改。哪怕是需求变更，也当如此。


这两个要求不是自相矛盾吗？对修改封闭，还怎么扩展？对扩展开放，源码还可能不变?

这两个要点看似相对，实质不是的。

扩展一个模块，不一定要修改它的源码：继承是一种思路；插件是另一种思路；策略模式等等设计模式也是一种思路；c函数库又是一种思路——不是高层模块，就把自己弄干净了等着被人调用就是，别掺乎架构上的事情。



相应的，那些良好设计的框架，模块，尤其是做为框架一部分的高层模块，就必须给出相关的配套设施——目标，就是设计一套漂亮的库，这个库要有一套漂亮的扩展机制，让使用者能方便的使用和扩展（开）；同时，库本身必须稳定、兼容（闭）：别像某些人的设计那样，一旦用了你的库，这下子可遭罪了，三天两头改，甚至动不动就得推倒重来，因为库设计又变了。

这TM是沾到裤子上的屎，不是库。


比如，观察者模式总会需要某种管理回调函数（或仿函数）的数据结构；然后，向这个数据结构中填写新的条目就是注册观察者，删除条目自然就是反注册了。

为避免不正常/不正确的利用这个数据结构，需要提供一组操纵这些数据结构的“算法”，然后把这个数据结构隐藏起来——这个说法好熟悉……
这个模式就可以在不改动主模块源码的前提下，扩展任意数量、任意功能的子模块。


类似的，几乎任何扩展都可以利用这种专用于扩展的“数据结构+算法”提供支持——所谓的“设计模式”，其实就是这种东西的一组实例。

有一定工程经验的老程序员，可以在2、3天内掌握一个新的语言/库/框架，就是因为，他们一看到具有某种特征的数据结构/接口（算法入口）——也就是特征数据结构和特征算法——就能心领神会：原来这种库设计给用户的扩展接口是这样啊。

——很显然，程序=数据结构+算法 不仅没有弱化，事实上，它反而被现代编程实践给推广、强化、扩展了。以至于抓住这个纲，一切就尽在掌握。
——如何识别这些特征数据结构/算法呢？这，就是面向对象想提供的东西，也是《设计模式》这本书想要教给读者的东西。


只可惜，无论是面向对象还是设计模式，都几乎是在出现的同时，就被人理解错了，然后就被大规模应用到它不适合不擅长的领域；甚至还搞出一套套走火入魔的“面向对象程序设计”方法论来。

理解错的原因，就是太多人想一步登天，却不知在那些花里胡哨的东西后面，是 数据结构+算法 这个平凡、朴实的根基。

sqfasd

回复 49# shan_ghost
茅塞顿开！
感谢，还有楼上几位