討好女朋友的6大技巧
前言
今天碼仔沒有加班，早早的回到了寬敞且明亮的家里，剛一推開門就聽到女朋友的聲音：“飯在鍋里，我在床上。。。。”
叮鈴鈴。。。。
好吧，鬧鐘聲不僅打破了清晨的寧靜也打破了碼仔的美夢。。。程序員還想要女朋友?
但是!碼仔心里最不爽的是不僅沒有女朋友，每天還要跟不同的“對象”周旋。
程序員的世界里有這么一句話：”萬物皆對象“，我們每天都再跟各種”對象“打交道，每天用各種方法來處理“各對象”之間的關系。
碼仔就想了，為啥不能把工作中協調”對象“的方法用到自己身上呢?那樣自己是不是也能萬花從中過了?
說干就干，上方法!
只對自己的女朋友負責 —— 單一責任鏈
首先在代碼界，單一責任鏈原則的定義是這樣的：單一職責原則(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)當前對象所創建的對象。
任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發生交互，不要與“陌生人”發生直接交互，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。
”不要和陌生人說話“，都有對象了還出去沾花惹草肯定是不行的了，畢竟兩人戀愛要相互坦誠。只有一心一意想著對方，兩人的感情才能長長久久。
總結
以上便是面向“對象”的六大原則。熟練掌握這六大原則不僅能讓我們在物質層面更好的滿足“對象”(代碼都寫好了，鈔票還遠嗎?)，還能讓“對象”在精神層面滿足自己(對象都哄開心了，你離開心還遠嗎?)。所以無論是為了我們的幸福生活，還是為了我們的性福生活，我們都有必要學習好面向對象。加油吧!騷年
