※ 引述《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)