死迴圈，一堆人有這種本末倒置的觀念
寫到最後，通常會用這種理由來解釋自己的程式比別人品質更高

"你看，我這邊判斷得多麼精準，沒用到的就是不會執行到，多麼完美"
"你看，如果你想加額外的處理項目，直接在這底下開函數就可以了"
"你看，你完全不用管我這邊怎運作的，只要使用就行了，該出的例外訊息都會丟出來"

我要反問了
"現在不是額外的處理項目了，我們資料庫要換，處理方法要換，你能馬上改出來嗎?"
"現在合作架構有點異動，很多欄位(數量)都改變了哦"

最重要的
"現在XX功能出問題了，你打算怎麼讓別人知道該怎去追這麼BUG"
"你要怎麼讓別人知道你程式運作的方式以及調整架構的方式"

然後死盲點
"你真的以為用這一大堆判斷式確認沒有額外函數執行效率會比較高嗎?"

合作開發這種事情，一個人是幹不起來的
要讀別人的程式碼是必然，因為要合作，在來有BUG，即使你說你負責處理，退個一萬步總得讓對方知道怎把這條BUG報給你吧

有些人會問我，怎麼你說你的程式是OOP的架構，GET／SET怎這麼少，函數好像也沒開很多
我倒要反問一下這些東西跟OOP到底有啥關係了

大家常常看到的 Vehicle new Car new Bike覺得很完美對不對?
可是你有沒有想過那只是大準則，你真的一new就天下太平了嗎?，別妄想了

程式，最基本最重要的東西就叫做"流程(Step)"
所有東西都依賴於他，即便你是個OOP架構，你最終還是要給我個"使用順序"來完成事情
當你確定流程以後，才有資格說我按照使用狀況去封裝必要的程式碼

為什麼?因為這樣做才能讓合作對象最容易了解你在做什麼

怎樣算是一個成功的OOP，就看需求有變動(注意不是項目，多個欄位你就顯示不出來，請不要來亂)程式能跟著變化到什麼程度

最基本的，處理流程，順序，不同資料銜接的方式，在怎麼說都是需要靈活應變的
總不能說我的資料只能完美的給A情況使用，換成B，阿不好意思我要大幅度改寫...
你再怎麼解釋你程式高效能，最終就是被貼一個標籤，應用方式太狹隘，思考太侷限


那怎樣算是一個失敗的OOP，近期看到一個例子，來分享一下
這個OOP相當省記憶體，因為只要沒有做到的他就絕對不會初始化，這點已資源考量方面是相當完善的

然而，他是怎麼運行的呢?
當我new 一個A類別，我就會執行一些B函數，但執行到一半為了處理事情我要用執行階段的部分內容呼叫C函數處理，然後執行完後我要直接拿這個結果呼叫D函數...
(後來想想，應該有人會看不懂，那白話一點，這個狀況就是:
你執行A類別，B函數以後，剩下的CDEFGHIJKL你除非去追原始CODE不然都不知道她怎幫你處理資料的)

問題來了:
這些所謂的function都是丟在該類別裡面，當有人問你
"請跟我說一下這程式處理資料的流程，我覺得好像有個地方執行怪怪的"

下場，很簡單，你要從頭到尾解釋一次程式給他聽，而且恐怕第一次解釋還聽不懂
因為function不管你怎麼整理，為了高效化就是有許多各自的細緻處理，最終的下場就是
"執行順序消失了"
這是相當嚴重的事實，我有正常跑我的類別，可是執行順序我都需要反查一下才知道跑到哪了


先不考慮過多判斷是否早已掩蓋掉原本直接執行的效率

剛才是不是有提一件事情
"現在，我的處理資料流程要變動了哦，稍微變動個執行流程，因為中間我們要加個驗證了"

然後好死不死，原作者不在現場
快，告訴我，哪個傢伙趕快神解一下這個類別到底該加在哪個位置

物件導向，是將事情正確的拆開封裝，以"方便溝通"，與"方便維護"，和"方便調整"
但這個模式同時隱含著你必須處理好運作流程，否則該封裝沒有意義

我一直不懂為什麼有些人會用效率去解釋他的OOP做得多好
你們TMD為什麼沒想過原本直接下一條指令就能搞定的東西，被你包了這麼多層
怎麼看都不可能比原本的效率還好OK? 你沒把最重要的流程，架構，溝通做好
還反過來說你看我這樣封裝，沒執行到的都被我精確排除了

抱歉，我只說一句，你正在拿最沒有效率的手段說你正在提高效率
請絕對不要做這種搞笑事情

以此觀點來說，沒錯，我也要講另一件事情
那些看起來很強的perfect coding，我就真的當它是都市傳說
因為那常常是特定狀況下才有辦法這樣幹，又或者是自身已經對資料架構摸到熟到不能再熟，且資料架構也沒啥大問題的狀況下，才有可能完美呈現的CODE

很抱歉這個需求我就是要動到5個資料表，你要我用處理單一資料表的水準把程式跑出來
這就是不可能的事情，請不要對著這支程式說
"你看人家對(單一)資料表都處理的那麼完美，怎麼你的處理方式有點雜亂"

當你正在想這件事情的時候，請自己寫一下真正會變怎樣
如果全部都能照你所想的正確呈現出來，那你真的可以去讓對方信服

反之，雖然處理漂亮了但判斷變超複雜，STEP變超複雜，你TMD還是來亂的
因為根本就不可能這樣改寫

有些理論只存在理想，如果你覺得他可以實際用出來
請拿實際能辦到且自己正在應用的事情來說服別人(不是拿其他人的程式碼哦，這有天地般的巨大差距)，而非只是宣傳一下好像很強的理論
就以為自己也辦的到，且這很完美，怎麼別人都不聽你的

理想與現實，一直都是兩回事，身為一個程式設計師，請務必先釐清這件事實