為什麼要物件導向呢

之前寫過一篇如果你也是.NET程式員，收到不少留言，各種意見都有，之前的說話方式不夠友好，特此向因看過而心生鬱悶的人道歉。

     問題在於我為什麼不停的提物件導向呢。說來我並不是物件導向聖徒，我真正想說的是“結構化”的編程思想和程式碼群組織方式的培養和習慣，我說的結構化是“有結構的“，這樣的結構包括但並不限於面向過程和物件導向。

       這樣就有個問題，比如“我自己獨特的結構”不也是”結構化”嗎。Martin Fowler的重構的裡有說“任何一個傻瓜都能寫成電腦能理解的代碼。唯有寫成人類容易理解的代碼，才是優秀的程式員”，代碼如果僅僅給電腦讀那怎麼寫都無所謂，只要是正確的代碼總能執行，但是我們的代碼是需要維護的，一般的代碼更多還是要讓人能輕鬆的讀懂，所以“自己獨特的結構”只能自己看。所以話說回來，大家都知道的，比較流行的“結構”包括但並不限於面向過程和物件導向這兩種方式。 然而就算是面向過程與物件導向這兩種， 就算是其中之一，你堅持了嗎？比如My Code到底是面向過程還是物件導向，還是很混亂 就算無所謂，My Code能讓人輕鬆讀懂嗎？

      面向過程或者物件導向的代碼就一定方便閱讀嗎？不管出於什麼樣的原因業界流行這樣兩種。先是以C語言為代表的程式設計語言，以及面向過程的編碼方式，接著後來以java語言為代表，物件導向的編碼方式(我僅僅說的是代表，說的兩個方面), 我們在學校的學習以這些為基礎，工作中必然也是也這些為基礎交流。如果我們堅持面向過程，或者物件導向，就為我們的程式方便閱讀提供了前提。怎樣才能體現物件導向和面向過程這兩種其中之一呢。如果你一直以C語言編程，堅持面向過程編程中的一些原則，那麼今後受過良好面向過程訓練的人就比較容易閱讀你的代碼了不是嗎。如果你以java或者C#編程， 堅持物件導向設計與編碼的一些原則，不是為一個受過良好物件導向訓練的人讀懂你的代碼提供了方便嗎？

      我為什麼說物件導向呢？我更要時候的是堅持“結構化”，如果你能寫出優秀的面向過程的設計也很好啊。如果你堅持用C#來做面向過程的開發也行啊，希望下個接替你位置的人也是用C#寫面向過程代碼的人吧。不過更多的是一個用C#寫代碼的人接受的是物件導向方面的訓練。用C也可以寫出物件導向的設計啊，不知道有人看過ooc這本書呢，（這本書裡介紹用C語言寫物件導向的代碼，弄的很複雜），應該有很多人不知道用static可以讓一個.c檔案的變數，結構和函數變成私人的吧。只是這樣，一個只進行了面向過程訓練的人能輕鬆看懂用C做的物件導向開發代碼嗎。 所以一個.net小項目就不要物件導向了嗎，說不定哪天因為功能擴充變成大項目了呢，更說不好將來維護的人根本就沒接觸過面向過程，就算一個小項目對他來說面向過程的一些做法也讓他看不到懂呢？

       所以我為什麼堅持要讓設計和代碼物件導向呢？因為用.net本是是物件導向的開發庫，而用C#做開發的人很多都是物件導向的程式員，所以為了方便交流我們不是應該盡量用物件導向的思路來做開發嗎？而且物件導向的思路也不僅僅是寫出容易閱讀的代碼，物件導向的各種好處也不需要我說了吧. 從最開始寫機器碼，到彙編，進階語言，再到進階語言中出現物件導向語言。物件導向應該是能解決很多問題才出現的吧。

      在這裡弱弱反對一下“完全貫徹實用就好，能解決問題就行，給錢就行”的觀點，軟體工程師總需要有點信仰，有些堅持的吧，如果軟體不僅僅只是你混飯吃的工具的話，而且就算是工具，你也不能讓你的工具隨便讓人動不是嗎。 小小程式員的一點感慨，貽笑大方了。