※ 引述《piimaila (haha)》之铭言： : 小弟大学时教程式设计的教授说过, 不要写大程式, 程式越大, 撰写和debug难度越大 : 所以基本上, 程式的实作方法, 我都是大的切小的, 小的切更小, 个人写的东西 : 单一档案过千的, 基本上都很难看到, 这种大小, 很多的时候用一个class就超过了 : 在我的感觉OO等等, UML规划等等, 感觉上都是脱裤子放屁, 继承和basic的goto : 在小程式中, 感觉上根本是一样的东西, 就算扣除OO工具开发出来的东西 : 大, 慢, 无法准确控制硬体的缺点, 纯粹就写程式开发方面来说, 我体会不出好处 : 因为要把程式搞的这样大, 大到会觉得OO好用, 已经是写普通工具程式 : 不合理的设计方法了 这是不同的 programming paradigm 的问题。 就 structural programming 的角度来说，解决软体复杂度的方法，就是 divide-and-conquer, 有个着名的复杂性定律： complex(a + b) >= complex(a) + complex(b) 因此将一个系统拆分为多个小程式，小程式拆分为不同模组，模组拆分为 不同函数，直到复杂性无法藉由拆分来降低为止，这个方法无论在过去、 现在还是未来，都会是有效的。 我们甚至可以证明，若是在解决单一问题以求得一个结果时, functional programming 在目前已知的方法中最具优势，若是在解决一个确定范围的 可能问题时, structural programming 也是已知的最佳方法。 然而 object-oriented programming 所要处理的，却是一个具有扩展性的 问题域，对应到实际层面来说，就是不断变动的需求，不断维护的系统。 如果你不需要面对客户多变的需求，不需要长期维护修改软体系统，那麽 structural programming 将是最佳方法。这跟什麽可读性是没有关系的， 确实掌握 structural programming 精神，并运用对应的软体工程方法， 仍然可以做出优美的工程极品。 只是，面对这个变动愈来愈大的世界，这个源自 Descartes "Discourse on the Method of Rightly Conducting One's Reason and of Seeking Truth in the Sciences" (即笛卡儿《方法论》) 并由 Edsger Dijkstra 引入至程式语言理论的 structural programming, 已经很难简单运用在 现代的软体开发上了。 我不认为在任何情况下都用 C++ 是最好的方法，但是 OOP 的精神，仍然 会是现代的 programmer 必须掌握理解的，软体技术为何会发展成今日的 模样，除了软体公司每几年都一定要搞一次的流行技术名词炒作之外，更 有着其深刻的意义。 我们之所以会需要 OO, 就是因为我们逃不开需求的持续变动。 电脑已经和人类产生了共生的关系，每一套系统都会和一些人以及一些事 有着长期互动，软体所要面对处理的，不再是个别问题的答案，也不再是 特定的功能需求，而就是这麽一些人和这麽一些事。当然，不是每个软体 都这样，但这已经不只是潮流而是现实，想要吃这行饭，几乎就是逃不掉 这个状况。 讲得简单一点，就是软体没有不改版的，系统没有不修改的。在写程式时 不管是用什麽方法，就是要去思考这件事。 -- ※ 编辑: semop 来自: 61.222.173.26 (01/13 13:06)