close
學鏞辭典
單字：OOOO（Obsessive-Object-Orientation Obliquity）
發音：KK: [O`OOO] DJ: /O`OOO/
解釋：n. 【醫學】【電腦】過度物件導向偏頗症，是一種過度使用物件導向（Object-Orientation）的病症，好發於年輕的程式員身上。屬於接觸性傳染，帶原者包括了不良的程式設計書籍和不夠專精的程式設計老師及同事同學。
例句：
1. OO Advocates tend to be OOOO patients. OO 擁護者很容易就會變成 OOOO 的病人。
2. People with a good understanding of computer science can get rid of OOOO. 對於資訊科學有深入的瞭解可以避免 OOOO。
3. Most OO experts used to be OOOO victims. 大部分 OO 專家都曾經是 OOOO 的受害者。
為了要有模有樣，我發明 OOOO 這個詞時，還特別參考了心理學的強迫症（obsessive-compulsive disorder），原本想叫做 obsessive-object-orientation disorder（OOOD），只是我不喜歡在這個詞的最後使用 disorder，我於是用 O 開頭的單字 obliquity 來取代 disorder，剛好形成四連 O 的詞。
當今 OOOO 的感染者人數眾多，數量直逼想靠樂透彩發大財的愚夫愚婦。他們常常有嚴重的幻想，認為全世界最了不起的東西就是 OO，成天開口閉口都是 OO，寫程式時只管大用特用 OO，完全不管 OO 所帶來的負面影響。
許多錯誤的資訊，是造成 OOOO 普遍的原因。例如下面的說法，在許多書上都看得到：
物件導向是很自然的，教導一個小孩物件導向比教導一個電腦教授更簡單，因為教授已經太熟悉電腦內的運作，所以比較難建立正確的物件導向觀念。
上述的說法並不正確，但是許多人卻都以為這樣的說法是對的。我認為這樣的說法錯在於：
1. 只要對於電腦運作原理的認知不夠，很難真的學會 OO，因為 OO 畢竟是用在電腦上的。許多人通常只能瞭解封裝，對於繼承不能完全掌握，對於多型更是難以捉摸。
2. 只要對於電腦運作原理的認知不夠，規劃出來的 OO 一點都不實用。可能是效率太差，可能是彈性太差，問題很多。
OOOO 患者寫出來的程式常常會有下列的病徵：
1. 太多類別：每個類別重用率極低，造成記憶體浪費太多。通常這樣的狀況，必須適當地利用繼承來改寫，或把功能類似的數個類別濃縮成一個類別。
2. 太多繼承：繼承固然可以提高重用率，但是也會使得物件體積變大許多，而且執行效率也會變差。繼承被誤用的情況一直很嚴重。更糟的是，繼承是一種靜態的關連，使得程式的彈性變差。許多時候，繼承可以用 associate 來改寫。
3. 太多物件：通常前述的「太多類別」會造成太多物件的狀況，但是即使類別不多，也有機會造成太多物件的狀況。一個程式使用太多物件會造成記憶體浪費。其實在許多時候，物件可以彼此共享的。
4. 太多短命物件：這會造成建構（construct）和回收（reclaim）花的時間太多，對於系統效率有很不好的影響。許多程式員的程式中有許多短命物件，但他們卻完全不自覺。可以使用 Object Pool 等方式來改寫。
5. 太多視覺元件：「太多物件」已經很不好了，如果這些物件是視覺元件，更是雪上加霜。視覺元件需要耗費 CPU 大量的運算能力。
6. 太多執行緒：其實從 OO 至上的角度來看，每個物件都是一個執行緒是最 OO 的，但是這樣顯然實際上不可行，因為佔用太多 OS 的資源，效率會變很差。
想擺脫 OOOO，你需要花好幾年的時間。建議各位好好研究 Java Swing，這是一個將 OO 發揮到極致又不失彈性和效率的 API。上述的六個 OOOO 的病徵，Swing 完全都沒有，足見 Swing 設計的巧妙。
OOOO 固然不好，但千萬不要因噎廢食而不用 OO，畢竟 OO 還是好東西，只是再好的東西都要適量。想擺脫 OOOO，您不妨多學習一些好的 design pattern，並認識作業系統、編譯器、以及程式語言內部的原理。
因為要準備博士候選人資格考，
看了一整天的Head First Design Pattern...再次推薦這本好書！
後來閒暇之餘在O'Reilly網站上找書時發現到這篇小文章，
看了深有同感，
特別是這學期身兼OOP助教，
到時應該會看到很多感染OOOO病人吧！
或是ANOO的病人...Absolute No Object-Oriented? 笑~
不過我覺得會導致OOOO病人越來越多的原因絕對跟現在市面上充斥一堆非常爛的書有關，
特別是書名中有類似：輕輕鬆鬆學、快樂學等關鍵字，
也很容易看到有那種書名寫著C++卻用很多C概念所寫的書，
於是很多人要不就是完全搞不董OO是什麼回事，
就是K了幾本爛書就以為自己會使用OO了，
可是卻連一個完整的軟體如何分析設計都沒做過，
於是學鏞辭典裡面所述的幾個病徵就出現了，
所以對於想學程式設計的人，
我不反對挑中文書...畢竟原文書真的很貴，
但是還是多挑一點原文翻譯書吧！
想學C++嗎？
侯捷先生幾本翻譯書都是很不錯的選擇！
想學Java嗎？
蔡學鏞先生幾本翻譯書(Head First Java亦是不錯的"觀念"入門書)和O'Reilly系列的書籍也很不錯！
想學美術設計嗎？呵~好像偏離主題了...其實這是我的興趣之一，
上奇出版社及無限可能創意出版社也是不錯的選項，
也許有人認為他們只是封面排版比較漂亮而已...也比較貴一點，
不過如果連一本書都排的不漂亮，
你確定那本書的作者能教會你什麼嗎？
此外別以為K了幾本書就自認為自己是C++/C#/Java或是VB的高手，
程式語言只是語言！
一個高超的軟體工程師就算只會一個語言，
也比會很多語言卻完全不會設計的程式技師強太多了！
最後...除了語言、設計、規劃及管理外，
多充實自己的Domain Knowledge才是上上之策。
單字：OOOO（Obsessive-Object-Orientation Obliquity）
發音：KK: [O`OOO] DJ: /O`OOO/
解釋：n. 【醫學】【電腦】過度物件導向偏頗症，是一種過度使用物件導向（Object-Orientation）的病症，好發於年輕的程式員身上。屬於接觸性傳染，帶原者包括了不良的程式設計書籍和不夠專精的程式設計老師及同事同學。
例句：
1. OO Advocates tend to be OOOO patients. OO 擁護者很容易就會變成 OOOO 的病人。
2. People with a good understanding of computer science can get rid of OOOO. 對於資訊科學有深入的瞭解可以避免 OOOO。
3. Most OO experts used to be OOOO victims. 大部分 OO 專家都曾經是 OOOO 的受害者。
為了要有模有樣，我發明 OOOO 這個詞時，還特別參考了心理學的強迫症（obsessive-compulsive disorder），原本想叫做 obsessive-object-orientation disorder（OOOD），只是我不喜歡在這個詞的最後使用 disorder，我於是用 O 開頭的單字 obliquity 來取代 disorder，剛好形成四連 O 的詞。
當今 OOOO 的感染者人數眾多，數量直逼想靠樂透彩發大財的愚夫愚婦。他們常常有嚴重的幻想，認為全世界最了不起的東西就是 OO，成天開口閉口都是 OO，寫程式時只管大用特用 OO，完全不管 OO 所帶來的負面影響。
許多錯誤的資訊，是造成 OOOO 普遍的原因。例如下面的說法，在許多書上都看得到：
物件導向是很自然的，教導一個小孩物件導向比教導一個電腦教授更簡單，因為教授已經太熟悉電腦內的運作，所以比較難建立正確的物件導向觀念。
上述的說法並不正確，但是許多人卻都以為這樣的說法是對的。我認為這樣的說法錯在於：
1. 只要對於電腦運作原理的認知不夠，很難真的學會 OO，因為 OO 畢竟是用在電腦上的。許多人通常只能瞭解封裝，對於繼承不能完全掌握，對於多型更是難以捉摸。
2. 只要對於電腦運作原理的認知不夠，規劃出來的 OO 一點都不實用。可能是效率太差，可能是彈性太差，問題很多。
OOOO 患者寫出來的程式常常會有下列的病徵：
1. 太多類別：每個類別重用率極低，造成記憶體浪費太多。通常這樣的狀況，必須適當地利用繼承來改寫，或把功能類似的數個類別濃縮成一個類別。
2. 太多繼承：繼承固然可以提高重用率，但是也會使得物件體積變大許多，而且執行效率也會變差。繼承被誤用的情況一直很嚴重。更糟的是，繼承是一種靜態的關連，使得程式的彈性變差。許多時候，繼承可以用 associate 來改寫。
3. 太多物件：通常前述的「太多類別」會造成太多物件的狀況，但是即使類別不多，也有機會造成太多物件的狀況。一個程式使用太多物件會造成記憶體浪費。其實在許多時候，物件可以彼此共享的。
4. 太多短命物件：這會造成建構（construct）和回收（reclaim）花的時間太多，對於系統效率有很不好的影響。許多程式員的程式中有許多短命物件，但他們卻完全不自覺。可以使用 Object Pool 等方式來改寫。
5. 太多視覺元件：「太多物件」已經很不好了，如果這些物件是視覺元件，更是雪上加霜。視覺元件需要耗費 CPU 大量的運算能力。
6. 太多執行緒：其實從 OO 至上的角度來看，每個物件都是一個執行緒是最 OO 的，但是這樣顯然實際上不可行，因為佔用太多 OS 的資源，效率會變很差。
想擺脫 OOOO，你需要花好幾年的時間。建議各位好好研究 Java Swing，這是一個將 OO 發揮到極致又不失彈性和效率的 API。上述的六個 OOOO 的病徵，Swing 完全都沒有，足見 Swing 設計的巧妙。
OOOO 固然不好，但千萬不要因噎廢食而不用 OO，畢竟 OO 還是好東西，只是再好的東西都要適量。想擺脫 OOOO，您不妨多學習一些好的 design pattern，並認識作業系統、編譯器、以及程式語言內部的原理。
因為要準備博士候選人資格考，
看了一整天的Head First Design Pattern...再次推薦這本好書！
後來閒暇之餘在O'Reilly網站上找書時發現到這篇小文章，
看了深有同感，
特別是這學期身兼OOP助教，
到時應該會看到很多感染OOOO病人吧！
或是ANOO的病人...Absolute No Object-Oriented? 笑~
不過我覺得會導致OOOO病人越來越多的原因絕對跟現在市面上充斥一堆非常爛的書有關，
特別是書名中有類似：輕輕鬆鬆學、快樂學等關鍵字，
也很容易看到有那種書名寫著C++卻用很多C概念所寫的書，
於是很多人要不就是完全搞不董OO是什麼回事，
就是K了幾本爛書就以為自己會使用OO了，
可是卻連一個完整的軟體如何分析設計都沒做過，
於是學鏞辭典裡面所述的幾個病徵就出現了，
所以對於想學程式設計的人，
我不反對挑中文書...畢竟原文書真的很貴，
但是還是多挑一點原文翻譯書吧！
想學C++嗎？
侯捷先生幾本翻譯書都是很不錯的選擇！
想學Java嗎？
蔡學鏞先生幾本翻譯書(Head First Java亦是不錯的"觀念"入門書)和O'Reilly系列的書籍也很不錯！
想學美術設計嗎？呵~好像偏離主題了...其實這是我的興趣之一，
上奇出版社及無限可能創意出版社也是不錯的選項，
也許有人認為他們只是封面排版比較漂亮而已...也比較貴一點，
不過如果連一本書都排的不漂亮，
你確定那本書的作者能教會你什麼嗎？
此外別以為K了幾本書就自認為自己是C++/C#/Java或是VB的高手，
程式語言只是語言！
一個高超的軟體工程師就算只會一個語言，
也比會很多語言卻完全不會設計的程式技師強太多了！
最後...除了語言、設計、規劃及管理外，
多充實自己的Domain Knowledge才是上上之策。
全站熱搜
留言列表
