Re: [閒聊] OOP小評

看板Soft_Job作者TonyQ (心存善念盡力而為)時間9年前 (2015/03/03 09:00)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串11/43 (看更多)

※ 引述《csfgsj (Lazy bone)》之銘言： : 這應該是GUI吧! : 跟UI比起來 : GUI程式是一個很大的程式，但你只是在寫其中的一小小部分 : 通常就是組態設定參數初始化作業 : 以及 : 事件訊息發生時的對應程式 : 這個訊息通常來自於Polling whileloop : (寫單晶片的都知道這只是基本款) : 不過你可能不容易見到它，甚至連程式的main()都不知去向 : (有些初始化作業跑到建構子裡去了，也看不到) : (繼承後會不會亂成一堆，也是眼不見為淨，你家的事) : 原因是 : 由於每一支GUI程式大架構都一樣 : 只有相對很小部分的組態及事件訊息對應程式需要客製化 : 因此XX都會將它包成Framework : 只有需要客製化的部分才揭露出來給你修改 : (剛開始還沒oop化) : 再加上OOP化之後，就是你現在看到的樣子 : (那些難看的Code都被 "封裝" 到電鍋裡了) : (放心，它們再也不會跑出來煩你了) : (電鍋裡有沒有蟑螂，也不會讓你知道，至少吃飯時的不會覺得噁心) : 從以前的MFC到現在的Android App 都是如此 : (C++與JAVA是一家人) : 但從此 : 寫GUI程式，在Framework內，都會有一種沒頭沒腦的感覺 : (反正一堆人天生無腦，這種問題一點都不困擾) : 另外還有一個向量化的問題 : 這些Framework的設計者，都是智商高的天才 : 把你們會作的事，都事先想到想好了 : (它們想不到的，你們一定也想不到) : 對User揭露的操作介面有些已經不是Library，而是設定參數 : (ex:layout.xml..etc.、傻瓜才用更簡化的 *.txt) : 包含圖形物件的繪製，也盡量向量化 : 用幾個簡單的向量，來決定圖形物件表現 : 用批次化的處理，來取代一個Pixel一個Pixel的繪製 : (所以大家的GUI外觀，看起來都一樣，整齊劃一真好) : 上包加下包，這就是GUI的現況 : : 重構也是有範圍力度的分別的 : : 他並不是「打掉重刻」這種革命 : : 也沒有人一天到晚都在重構 : : <Refactoring>這本書 : : 他有建議你適合重構的時機 : : 你可以自行決定需不需要重構 : Framework重構可是會死人的雖然我覺得你的核心立論基本上我是認同的，但推論過程問題實在是很多。我個人認為假設要以目前 Java 的 OOP 結構，（其實該說 class 階層與 interface ），他的問題在於 state 在繼承樹的前提底下，取用跟管理容易落入一個混亂而難以掌控的狀態。而層層繼承底下不同階層的功能，如果有需要同時需要垂直整合（向父層或子層尋求實作或狀態）與外部整合（引入外部類別進來實作，像策略模式）的時候，透過繼承那個複雜度是線性成長的。所以 ruby 引入 mix-in ，除了 interface 以外還引入實作，我個人覺得是個對 OOP 很好的反思。（這點的爭論，我是蠻推薦去看松本行弘的這本書，即使我不真的很喜歡 ruby ，但這本書在這個議題上討論挺精彩的。 http://www.books.com.tw/products/0010476366 ）某個程度上相對簡化這個問題，在繼承樹本身的水平跟垂直整合問題，直接可以引入外部實作。但同時 mix-in 對本身實作需要的狀態造成的「佔用」，則又引發新的複雜問題（簡言之，mix-in 撞到實作時基本上會痛不欲生）。對我來說，我現在的分類方式是粗淺的分成 OOP vs functional ，有無 OOP 事實上是「有無狀態」的載體差異。因為把爛 code 封裝起來，對小範圍逐步封裝，這回事是所有語言都在做的事情，不論各語言一樣都是這樣。（有沒有函式定義的通用語言嗎？）無論如何，我認為 OOP 只是個基本原則之一。以我現在的實作來看，我實作 OOP 與 util/helper ，作純 function (純in/out) 沒有 state 的 code ，大概是 6:4 的狀態。另外我自己也會盡量控制繼承樹不要超過三四層，來降低複雜度。管理狀態並不總是好事，很多時候他造成測試上的困難，造成狀態因為長時間持有產生的不穩定性，你不見得知道中間經手過的每個人是不是都照著契約走，當然我們可以把這個契約訂得很死，（ex. 每個 field 都設 private 跟只提供特定一定符合規範的操作函式）但那樣開發成本也是指數上升。但這跟什麼鬼重構一個 framework 會死人跟什麼沒頭沒腦是兩回事。你爽的話可以用 oop 寫一個有頭有腦的東西。只是接下來就會有另一個人跳出來說你寫的東西讓他沒頭沒腦。對我來說，視需要修改所有開源的 framework 都是很正常的事情，很多時候問題是有沒有必要，不是要不要修，能不能修，修不修得動。另外談到亞馬遜叢林與定性定量問題，這其實是個哲學問題。熱力學第二定律，凡做功必產生熵，換言之，沒有絕對不產生雜訊的行為，而這個熵大多測不準。照你的說法，我們的生活層層疊加之後其實跟你所說的亞馬遜叢林沒差多少。但其實即使如此還是可以透過「契約」與「評估」取得秩序問題的平衡，問題不在做功會產生熵，因為沒有不產生熵的東西。問題在我們是否已經找到最有效率的解法。你文章對這點的推論不能說是錯，但也不能說是對，因為沒有看到不會產生這個問題的方案（functional ...etc ）。在這前提底下去批評一個現有的（最好？次好？）方案，其實是對多數人來講是沒什麼價值的。就像說呼吸地球空氣有害一樣，除非你能找到有地方能供應更好的氣體，不然這句話跟廢話沒什麼兩樣。 oop 不是唯一解，不是最好的，但一個好的能自我管理的狀態機制，對這個寫程式的世界其實是很有幫助的。 -- 最近有個缺點就是即使多言如我，對這種事情也很難再寫出千字文「以正視聽」了。寫文章說真的還是處於一個有氣無力，但我實在又不願意毫無內容的批判，還是簡要寫一下駁論的核心，不足之處請自行申論再看狀況回應。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.228.183.125 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1425344418.A.0A1.html ※ 編輯: TonyQ (61.228.183.125), 03/03/2015 09:10:51 ※ 編輯: TonyQ (61.228.183.125), 03/03/2015 09:11:27

‣ 返回看板[ Soft_Job ] 工作

‣ 更多 TonyQ 的文章

文章代碼(AID): #1KzGUY2X (Soft_Job)