我是白痴orz

程式設計中物件導向的基本方式通常都是由下往上的設計，也就是先設計出很多小元件，再逐漸規劃把這些小元件拼成大程式，以譬喻來說，一輛車子，使用物件導向思考的人會先規劃輪胎怎麼設計，引擎怎麼設計這些問題，這些問題解決後再考慮輪胎和引擎、外殼怎麼組合，駕駛者怎麼和車子互動之類的問題，而逐步把元件設計成車子。這是程式設計師的思考習慣之一。

程式設計師的思考習慣之二，就是凡是都要先經過詳細、整體的規劃才投入行動。譬如系統程式的設計，必須先考量諸多的環境問題，如：微軟的作業系統下多執行緒怎麼動？作業系統的「message」如何由系統傳遞到應用程式？網路設計的部份要blocking還是non-blocking？兩執行緒之間怎樣傳遞消息？如何避免死結的問題？考量完環境的問題以後還要考慮設計的問題，雖然物件導向帶來的封裝、多型、繼承等機制的確成功把程序導向混亂不堪的副程式和變數分散到其應有的位置。也將「一個函數、多種類型」的巨大switch問題以template、繼承、虛擬函數、函數多載等方式解決，但是這些功能一方面帶來了便利，但是本身也帶來了language feature的問題，程式設計師往往要仔細考慮：一個exception丟出來往上游傳遞的過程中，stack unwinding的過程會不會造成重要系統資源沒有被解構子釋放出來.....。就算物件導向的部份都沒問題，物件之間的互動還是問題（雖然比程序導向簡單），要怎樣設計才能達到最容易除錯、最不容易出錯、最容易擴充.....總而言之就是要先想很多問題啦orz

程式設計師的思考習慣之三，就是多一秒規劃、少三秒除錯，轉化為行動，就是一件事情不但要考慮他的輪廓、還要考量到所有可能會影響到結果的細節....

基於這些原因，我程式設計花時間（不包含除錯），其實大部分的工作時間都是在公車上、在課堂下課時、在老師講廢話時。以班網來說，我常常在公車上想權限系統和互動網頁互動的問題XD

這樣思考的好處是巨細靡遺，出錯率低，理論比較週到。有時在BBS上和人辯論，可以一篇文章終結一個討論串。但是現實生活中這種方法不是這麼好用orz

比如和媽媽吵新聞上「政府應不應該追究某些歷史事件」的問題，我會說：那些歷史事件是重大歷史事件，真兇未明，社會正義還沒有100%彰顯，所以應該追究，故就事件性質而言，政府有權且應該追究。但是政府施政上除了追究歷史事件這個該做的事情以外，還有很多其他的事情和追究歷史事件一樣也是該做的事情，並且更重要。所以政府應該優先處理施政、而先擱置追究歷史事件，倘若政府專心追究歷史事件卻忽略施政，應當處罰，但是此罰並非認為追究歷史事件錯誤，而是針對政府施政順序錯誤的問題。我以比喻可解：打電動沒關係，荒廢功課打電動有關系，處罰沈溺電動的小孩不是因為打電動有罪，而是荒廢功課打電動有罪。又如去健身房練身體是好事，但是聯考的孩子專心去健身房而不讀書就應該吃巴掌。依此譬喻，我的結論是歷史事件應該追究，但也不可以專攻歷史事件而忽略其他問題。綜合而言，歷史事件應該追究，但是專心追究歷史事件該罰。

我媽就簡潔明快的說：既然知道一味追歷史而忽略施政該罰，那麼為何還要這麼長篇大論？我想想也有道理。但是看國外對MP3科技的判例，也通常是「分割判決」，法官判決，絕對不會只說「MP3有罪、MP3無罪」這種籠統的結論，而會說「MP3科技無罪、但是亂用有罪、所以某些MP3下載網站應該禁止」這種部份、全體都顧到的論點，因為只有部份全體兼顧、不但內容要顧、表現方式也要顧。不但內涵要正確，還要引用....這樣才可以禁得起所有挑戰的攻擊。

不過今天我就被自己這套模式害了，今天H大叫我去前面關燈，我衝到前面看到燈沒有寫字，就很害怕：每個燈都有四分之三的錯誤機率，倘若錯誤就是干擾同學上課，同學、老師未必願意接受此種後果。最保險的提案是向會的人問。於是我就向S大問了（想說她可能知道orz），結果她像個真正的男子漢一樣衝到前面，每個燈試一試就搞定了，好像亂按也不會怎樣orz

所以我媽有道理：不要思緒停留在枝節事物上XD 全文連結