→ lachtchlee: hibernate 03/01 20:46
推 yauhh: 這不錯啊，有 domain knowledge 03/01 21:07
推 MIKEmike07: OO架構好debug? 03/02 02:28
→ csfgsj: 如果domain knowledge是細菌，那OOP一定是抗生素 03/02 13:12
推 AmosYang: 中肯 03/06 17:57
1. 早期把物件化的分析/設計思維歸為 OOA/OOD (Object-Oriented Analysis/Design)；
實現物件化思維的程式語言則稱之為 OOP (OO Programming)。
2. 實現 OO 思維主要有兩個機制：介面 (interface)、多型 (polymorphism)。包括
.NET/Java 等主流語言，早已支持 OOP，甚至連 php/python 等原來屬於
script-based 的程式語言，也朝向 OO 化的實現機制。
3. 從 OOP 的角度來看到物件化的設計思維是不妥的；原因在於絕大數開發人員並不知道
Why OO Thinking！其實採用 OO 設計化思維是必然會增加開發成本的。因為它並非為了
解決某一局部的邏輯性問題，而是考量全局，從系統整體來看待「變動 (Change)」的議
題，進而提出如何擁抱改變 (embrace changing)的解決方案。
4. 再則從實作上，OO 化的特徵是分散式的 (因為基於類別 (class)的責任分派
(responsibility assign)原則)。所以為了實現 OOP 的分散式架構，程式碼必然大量分
散於各類別內，如此會造成實作與偵錯的難度；因而一個必要的配套措施：TDD (Test
Driven Development)，測試先行是一定要養成的好習慣。
5. 越是大型變動頻繁、高度維護，或者期待包裝為產品，增加其再利用性價值的系統，
採以 OO 的設計/實現 (當然，前提要有這樣實在技能的軟體架構師/Developer)才能感受
到其好處：每一次只改變一點點；每一次的變動可以侷限在可控制的變動範圍內。
6. OO 的特徵是將 程序/資料 封裝至某一類別內，其實在抽象層次，程序稱之為「行為
(behavior)」、資料稱之為「屬性 (attribute)」，兩者均為物件必然會有的特徵
(features)，是非常自然不致分離的。但因現實仍沒有一種有效的機制能把物件的狀態
(state)儲存起來，所以實作技術上是把物件與資料分離，資料儲存於資料庫系統內、待
執行期間 (run-time)才透過如 OR Mapping (如 .NET ER Framework、Java Hibernet 等
)，將物件與資料合而為一。
7. 實業界很有趣的一個現象：重視 MIS (Management Infomation System)系統的公司，
幾採以資料導向的開發模式；重視 Web 框架如網路行銷公司，大都採以程序導向的開發
模式。至於所謂的 OO 化，實現的程度其實還蠻微小的。
8. 順待提下重構 (refactor)的觀念：重構是屬於事後 (Coding 後)的設計，一般與事前
(Coding 前，如典型的 SA/SD)設計可能存在著 3:7 或 4:6 (事前：事後)的比重。而且
往往寫完程式才是另一段故事的開始：持續重構 (continous refactoring)。
9. 重構的要件：不會影響到已經上線系統的所有功能。 衡量重構的指標：每一個
method 不會超過 10 行、最長不得超過 20 行。
10. 如今重視 Web 相關技術、快速實現商業創意的年代，其實已少人有人談及 OO 更遑
論具體實踐了。西元2000年以前，包括 UML 三大師 (Booch、Rumbaugh、Jacobson)、
Martin Fowler (重構一書即為他的著作)、Kent Beck (XP/Agile 的始祖)、Bob (Clean
Code 作者)均為支持物件思維的軟體大家。國外除了這些大師外，實現 OO 的專家其實也
不多，一般是會落在如開發底層框架 (如 .NET Framework)的關鍵架構師。
※ 引述《flyfoxy (飛狐)》之銘言：
: OOP不只是從GUI的角度出發，我以OpenCV這個第三方lib做為例子
: 我個人從OpenCV1.0開始使用到現在
: 他去年有了3.0beta版
: 我看到他從最早1.0版幾乎是c code，沒有使用class/namespace..etc
: 好在只是DLL function呼叫，c code 其實也還好，
: 如果有去trace過JM1.6版的c code，那真的令人暈頭轉向
: 又沒有UML的圖，function這個call那個，回傳值全部用
: pointer，到了另外一個地方又是另一個pointer名稱
: 但它是原先那個pointer傳過來的，這真的是純c code的痛苦。
: OpenCV2.0版開始他就更有結構化，使用class/namespace進行封裝
: 也建立了線上document分類分好
: 想要找特徵學習還是影像處理，一目了然。
: OOP絕對有他的缺點，比如看一個class發現他可能繼承於別人
: 然後就要再去看上層的class，有見樹不見林的感覺。
: 但如果document做的好，有類似Start UML的圖表，其實架構是很清楚的。
: 或者說過多的繼承會導致class十分龐大臃腫
: 或者說資料和程序難以分開 導致十分難trace
: 我也曾經在如何抽離介面和演算法之間徬徨
: 但其實這些問題不是不能克服的
: 微軟的Doc/View模式某種程度上就已經幫了你一點忙
: 甚至其實是coding習慣的問題，因為一開始架構就沒有寫清楚
: 或是時間不夠流程和資料就混成一堆，程式能動就好，
: 或是因為後續的需求變更使得class間的耦合性變得更複雜
: 所以當你程式越寫越大，你就越早面臨「重構」這件事情
: 上述的問題透過「重構」其實都可以得到解決，
: 只是大家應該都沒時間「重構」，
: 或者說因為「重構」不會讓你薪水變多，只是事情變多，
: 但我覺得應該要推廣一個觀念
: 如果一個軟體想要「永續經營」，「重構」這件事情是必要的
: 除非你寫了一隻程式，以後都不會去改動它，
: 都沒有維護/增加功能的問題。
: ※ 引述《csfgsj (Lazy bone)》之銘言：
: : From護法兄
: : 有些人愛用oop，或許真的有一些理由
: : 從Gui的角度來出發，也許真的是一個蠻契合的Paradigm
: : 但一個Paradigm適用範圍畢竟有限
: : 出了這個範圍，若還是要硬套，那就是自找麻煩
: : 就我的觀點來看，OOP裡的確有不少討厭、自找麻煩的東西存在
: : 什麼是理工學生的思維模式？以及
: : 十數載在學校的學習，是在作什麼？
: : 能不能用幾個簡單的字來詮釋它？
: : 我的理解就這四個字：
: : 定性、定量
: : 即對世間的事物，學習培養對其定性或定量之能力
: : 什麼物理、化學、數學等理工學科都一樣，都是在作這樣的事，沒有例外
: : 而且能否對事物作定性定量，也就成了評量對事務是否了解的普世標準
: : 漸漸地，它成為所有理工學生的思維基礎
: : 處理陌生事物前，要先對它作有效的定性定量
: : 這樣的作法也就理所當然，成為標準程序
: : 反過來說，一個遲遲無法定性定量的事物
: : 就會成為理工科學生的困擾，甚至惡夢
: : 尤其是在無法逃脫非要處理它的情況下
: : 幾乎所有的軟體，都是由許多不同的軟體元件疊加起來的
: : 一個軟體工程師很可能只作其中的一部分
: : 其它的部分不是現成的，就是別人作的
: : 有很大的一部分，工程師的工作只是在整合這些元件
: : 我的問題是
: : 工程師在整合這些元件之前，能對它們作有效的定性定量嗎？
: : 不管是C++還是JAVA以及其他的OOP程式語言
: : 都有所謂Class的語法，並且大量的被使用
: : Class就是資料加程序的集合體
: : 有人說這是個好東西
: : 以我的觀點，它確是個萬惡之源
: : 資料是資料，程序是程序
: : 兩者是性質完全不相同的東西
: : 當你刻意將兩個性質完全不相同的東西併在一起成為一個東西之後
: : 其結果就是
: : 你創造了一個無法被有效定性定量的東西
: : 大量的無法定性定量的東西被創造出來，並且存在於程式之中
: : 程式會呈現什麼景象？亞馬遜叢林
: : 在亞馬遜叢林，一切都變的隱誨，似明未明
: : 基於本能，人在這時候往往採取保守小心的策略
: : 以免不小心，那邊冒出一隻大蟒蛇，把你一口吃掉
: : 隱誨、保守小心，也就是侷限的開始，愚化的淺勢開端
: : 由其是經驗不夠的時候，很容易就此走不出來
: : 因此
: : "工程師的缺德行為：叫朋友去學C++"
: : → bibo9901: 不同意, 並不是把 data 和 function 分開就看得清楚 02/28 20:58
: : → bibo9901: linus 指的 "substandard programmer" 應該就是這種吧 02/28 21:03
: : → rodion: 是否搞錯OOP的正確用法? OOP不代表任何東西都要用OOP 02/28 21:23
: : → lachtchlee: 笑話一則 02/28 21:41
: : → csfgsj: rodion觀念正確，但很多人不是 02/28 21:50
: : → csfgsj: 給lachtchlee：大家一起哈哈笑吧！ 02/28 21:51
: : 推 typepeter: 只想問閣下成就如何...XD 我認識Googler也沒像你這樣說 02/28 23:02
: : → typepeter: 看似說了什麼 卻全篇心得文 未有實際上作法 02/28 23:04
: : → typepeter: 你說堆DomainKnowledge, so? 除了聽起來很酷，然後? 02/28 23:05
: : → typepeter: 好像是發功程式就會出現一樣 有無具體作法? 02/28 23:06
: : → typepeter: 所謂D.K.要如何精鍊 如何判斷要不要用框架 有無具體? 02/28 23:09
: : 推 iceonly: 平平都是寫code，工作環境不同也有不同的心得，也許他的 03/01 01:20
: : → iceonly: 業務是個與OO無緣的世界，那也沒啥好批評的;反對OO的論點 03/01 01:23
: : → iceonly: 也很多，原PO說的也是常見的一種 03/01 01:24
: : 推 iceonly: 只是OO/DP/各種framework都只是為了降低維護成本的一種工 03/01 01:40
: : → iceonly: 具而已，不用那些或許達的到但是用了會簡單很多 03/01 01:41
: : → iceonly: 某種功能在短時間內純手刻就能實作/新增是很厲害沒錯，但 03/01 01:42
: : → iceonly: 使用上述工具就能在同樣時間內達到同樣效果時帶給老闆的 03/01 01:43
: : → iceonly: 效益是一樣的話那好像也還好 03/01 01:44
: : → iceonly: 感覺像是練過心算的在嘲笑用計算機的人一樣 03/01 01:46
: : → anguso: 我認識的 Googler 似乎都懶得對這種文回應... 03/01 06:02
: : → y3k: 我不相信沒有OOP能有效率地完成什麼大型專案 有些script工程 03/01 12:46
: : → y3k: 師喜歡批評OOP 但是我覺得那是因為他們用不到.... 03/01 12:47
--
FB 社團：軟體設計鮮思維
http://ppt.cc/~4VN
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.32.107.221
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425210043.A.915.html