碼個蛋(codeegg) 第 946 次推文
前言
今天碼仔沒有加班，早早的回到了寬敞且明亮的家裡，剛一推開門就聽到女朋友的聲音：“飯在鍋裡，我在床上。。。。”
叮鈴鈴。。。。
好吧，鬧鐘聲不僅打破了清晨的寧靜也打破了碼仔的美夢。。。程序員還想要女朋友？
但是！碼仔心裡最不爽的是不僅沒有女朋友，每天還要跟不同的“對象”周旋。
程序員的世界裡有這麼一句話：”萬物皆對象“，我們每天都再跟各種”對象“打交道，每天用各種方法來處理“各對象”之間的關係。
碼仔就想了，為啥不能把工作中協調”對象“的方法用到自己身上呢？那樣自己是不是也能萬花從中過了？
說幹就幹，上方法！
只對自己的女朋友負責 —— 單一責任鏈
首先在代碼界，單一責任鏈原則的定義是這樣的：單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義為：就一個類而言，應該只有一個引起它變化的原因。它具有高內聚，低耦合的特點。
也就是說，我們在設計類的時候，把實現某類功能的方法，合併到同一個類中，讓其只對單一功能負責，這樣可以很大程度的減少代碼耦合性。例如：我們封裝了一個圖片處理類用於處理代碼中所有圖片展示的問題，有圓角顯示圖片、圓形截取圖片、模糊圖片等等，到這裡都是符合單一責任的原則，這個類只對圖片的顯示處理負責。但是如果我們再把圖片的下載、刪除等方法封裝進來，這樣雖說類的功能更多了，但是其需要負的責任也多了，後期對其的維護和管理更麻煩了。
那這個原則應該如何應用到我們談對象中呢？其實是一樣的，單一責任，只對一個人負責任。我們只需要對自己的“對象”負責任就行了，別人的“對象”不需要你來負責任，你要強行對別人的“對象”負責任，那你大概率會打翻自己對象的醋罈子，然後強行搞崩你們之間脆弱的感情。
一諾千金 —— 開閉原則
我們先看一下開閉原則的定義：開閉原則(Open-Closed Principle, OCP)：一個軟件實體應當對擴展開放，對修改關閉。即軟件實體應儘量在不修改原有代碼的情況下進行擴展。也就是說，我們在維護和升級項目的時候，要儘量不去修改已經寫好的代碼（除非是Bug）通過繼承或者別的方式去新增功能。那這個原則又如何運用到我們談對象當中呢？
兩個人交往，肯定少不了一些保證、承諾什麼的，對於這些東西一定要牢記，切不可修改。不讓會給人家不守信，不靠譜的感覺，當你的女朋友對你有這種認知的時候，那你們的感情大概率要涼了。
分清範圍 —— 里氏替換
什麼是里氏替換原則呢：里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類（父類）的地方必須能透明地使用其子類的對象。就是說在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。這很顯然是通過繼承思想抽取的方法。那在生活中我們又怎樣通過這個方法好好跟對象交往呢？
陪對象一起吃飯也是個很麻煩的事情，因為她總有這些那些不吃的東西。有時候她會明確指出她不吃什麼（蒜啊、菠菜啊）但是有時候她會給你一個範圍：不吃青菜。如果她給你說的是不吃菠菜，那麼她也許會吃生菜或者其他青菜，但是如果她告訴你不吃青菜，你如果還是直男思想的給她吃生菜，還說：“你不是不吃青菜麼？這是生菜不是青菜啊！”那你這個腦子還是不用談戀愛了。
以不變應萬變 —— 依賴倒轉原則
我們先來認識一下這個原則：依賴倒轉原則(Dependency Inversion Principle, DIP)：抽象不應該依賴於細節，細節應當依賴於抽象。換言之，要針對接口編程，而不是針對實現編程。依賴倒轉原則要求我們在程序代碼中傳遞參數時或在關聯關係中，儘量引用層次高的抽象層類，即使用接口和抽象類進行變量類型聲明、參數類型聲明、方法返回類型聲明，以及數據類型的轉換等，而不要用具體類來做這些事情。而我們在實現依賴倒轉原則時，通常需要針對抽象層編程，將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發生依賴關係時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分別是：構造注入，設值注入（Setter注入）和接口注入。（依賴注入不僅解耦，還方便單元測試）
戀愛中給女朋友買東西是很麻煩的一件事，因為女人都是善變的。前一秒她還給你說她喜歡這個顏色的口紅，下一秒可能就變成了另一個顏色的包包。所以戀愛的時候與其猜來猜去，不如一步到位，直接給錢，以不變應萬變，想買什麼買什麼，方便還省事。（哎！可憐的碼仔，為了性福生活只能不斷搬磚了）
對症下藥——接口隔離原則
這個原則的定義是這樣的：接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。
接口隔離原則與單一職責原則都是對接口設計的規範。不過，單一職責原則強調的是職責的單一，即業務劃分上的單一；接口隔離原則強調的是具體實現時，接口的規模不能過大。比如，一個接口的設計符合單一職責原則，只包含一個職責的定義，但是實現這個職責需要較多的函數或方法，而並不是所有的模塊使用此接口時都會用到所有的方法，那麼這個接口的設計就不符合接口隔離原則。
不僅在編程中需要接口隔離，談對象同樣也需要 。廣大男同胞肯定都有一個通病：對象給你說不舒服，你回覆“多喝熱水”；對象給你說感冒了，你回覆“多喝熱水”；對象給你說無聊了，你回覆“多喝熱水" …… 熱水治百病。這樣我肯定你活不過三秒。什麼藥治什麼病，對症下藥才是王道。
不要到處沾花惹草——迪米特法則
最後一個原則，迪米特法則(Law of Demeter, LoD)：一個軟件實體應當儘可能少地與其他實體發生相互作用。迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對於一個對象，其朋友包括以下幾類：
(1)當前對象本身(this)；
(2)以參數形式傳入到當前對象方法中的對象；
(3)當前對象的成員對象；
(4)如果當前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；
(5)當前對象所創建的對象。
任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發生交互，不要與“陌生人”發生直接交互，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。
”不要和陌生人說話“，都有對象了還出去沾花惹草肯定是不行的了，畢竟兩人戀愛要相互坦誠。只有一心一意想著對方，兩人的感情才能長長久久。
總結
以上便是面向“對象”的六大原則。熟練掌握這六大原則不僅能讓我們在物質層面更好的滿足“對象”（代碼都寫好了，鈔票還遠嗎？），還能讓“對象”在精神層面滿足自己（對象都哄開心了，你離開心還遠嗎？）。所以無論是為了我們的幸福生活，還是為了我們的性福生活，我們都有必要學習好面向對象。加油吧！騷年
女朋友非要問我什麼是設計模式！
你是怎麼討好你的女朋友的？
