編程之代碼抽象三原則，這三原則仔細推敲，與23種設計模式不無關系。

23種設計模式，在此我不做詳細介紹和說明，因為我目前也正在學習，在學習設計模式的時候，有一點非常重要，

引用王陽明先生的理念“知行合一”，將理論同實踐集合起來，這樣就不空中樓閣了。

另外還在此補充一點，這裏我引用王船山先生的名言“實踐第一”。

編程是一門實踐性科學，缺少編碼的經驗，光談理論，那麽是行不通的。設計模式，是前輩們，GOF（四人幫）等編程經驗的總結。

形象的說，如果沒有一點功力的基礎，就想練九陰真經那是不行的。

只有當編程開發經驗達到一定的積累時，這時你會發現你不得不重視代碼的質量，之前我也強調過單元測試的重要，之所以重要是因為可以避免web界面測試犯錯誤，導致研發進度延遲和開發效率降低。

那麽這裏我要說明的時，當編碼時就要意識到你所要寫的代碼質量，這個質量可以用這麽幾個標準來衡量？

(1)給幾個月後的自己看和同事看，他們或者自己能否在較短的時間看懂(可維護性);

(2)當某個業務邏輯需要新增新的功能，是否在此基礎上新增接口或者方法就可以做到，而不是需要代碼重構或者重新寫一遍(可擴展性);

(3)當A類功能需要修改，不會影響到B類功能(耦合性低，軟件遵從原則“高內聚，低耦合”);

下面說的代碼抽象三原則，我相信大家對此並不陌生了。

一、DRY原則

DRY原則，翻譯過來的意思是"不要重復自己",用編程的話來概括，不要寫重復的代碼。

大家如果看過我的一些博客，應該可以看到，我時不時會強調這個DRY原則。

之前我就說過，Java的代碼生成器就是DRY原則較好的實踐例子，復制+粘貼雖然可以提高開發效率，但是那也是人力所為，也是需要時間的，代碼生成器將通用的增刪改查在一分鐘甚至半分鐘都不要的情況下，即可生成幾十張表的代碼(entity,dao,service,serviceImpl,controller,xml),而且這些代碼也很簡潔易懂，同時也不容易出錯，有的時候，即便的復制粘貼，人總是有粗心大意的時候，所以往往有時就是因為這樣，犯了一些低級錯誤。而計算機只要你給它的指令是對的，它幾乎是100%不會犯錯，前提是指令正確無誤。

DRY原則，無時無刻不再用，研發的夥伴們對此也不陌生了。

二、Shy原則

Shy,英文翻譯過來的意思是"害羞",Shy原則可以用設計模式遵從的一個原則“迪米特法則”，理念基本是一致的。

簡單的說，一個類盡量與其他的類發生聯系。

以我使用MyBatis的經驗為例:

比如有的時候我需要多表連查，需要獲取其他實體的信息，比如A、B、C三個實體，我以A為主，需要獲得B、C的一些屬性(字段)信息，通常根據一對多或者多對多，我在對應的xml加上association或者collection，並在該標簽類加上對應的字段和屬性，和在A實體加上List<B> b或者 C c即可。

就能達到目的，當然了最爽快的辦法是直接在A實體上加上B、C實體的屬性，但是那樣一來對於以後維護，將會增加非常大的成本。

特別是多人開發的情況下，如果不統一規範和遵從統一原則，那麽本來多人開發，有的時候因為溝通會導致一些問題，使研發進度延遲，同時也會因為代碼不規範嚴謹，亂七八糟導致項目Bug百出，研發人員就處於無止休的改Bug階段，要知道，牽其一而動其余的代碼，是極為不好的，因為這樣一來，改為舊的Bug，就會出現新的Bug。

很多時候互聯網企業，特別是中小型企業，由於不重視代碼規範和不養成良好的編碼習慣，導致總是在加班加班。

對於企業而言，增加的時間成本，從而導致少盈利,對於個人開發人員，因為自身不好的編碼習慣，導致無止休的改bug,雖然對於一些解決問題的能力有一定的提高，但是就我個人看法，很多bug毫無技術含量，改多了意義也不大，還不如養成良好的編碼習慣，寫一手優美的代碼(可維護，可擴展，低耦合),這樣可以拿出很多時間學習，學習新的技術，讓新的技術提高開發效率，讓工作效率高，讓整個團隊研發能力強，這樣一來，可以說，即可以迅速的漲工資，有能讓自己的能力更上一層樓，同時，對於成家立業的人，有更多時間陪伴自己的家人，對於男女朋友而已，可以有更多的時間在一起，互相增進感情。

三、三次原則

這個三次原則，最好理解了，簡單的說，當某一段代碼需要在三個或者三個以上的類需要引用，那麽將其抽象為一個方法進行調用，這樣可以減少冗余的代碼，代碼行數並不是越多越好，特別對於一個類來說，類中的代碼上千行和上百行，是需要加載時間的，加載時間越長，效率就不是特別高。有的時候，代碼真的沒必要上千行，就我開發期間，見過的代碼包括開源的代碼很少有上千行的，而且人家的代碼，也就是四五百行，簡單明了，而且又不少遵從三次原則。我哥也曾對我說過，無論是前端js或者java代碼也好，當這段代碼出現多次時，將其抽象為一個函數進行調用。另外我一個朋友他是在一家國企工作，他們公司目前基本處於項目維護階段，時不時就是根據客戶需求在原有的系統上修改或者新增功能，特別是他維護一個之前開發人員的代碼，發現一個非常讓他憤怒的事情，就是很多代碼出現重復的，而那些重復是可以通過抽象為一個函數引用的。

小結:

我希望我自己和編程朋友們，牢牢記住一點，讓編程變為一項優雅的智力活動，而不是重復的體力勞動。

編程之代碼抽象三原則