建站
咨詢
售后
建站咨詢
新聞中心
前言
網(wǎng)站設(shè)計制作過程拒絕使用模板建站；使用PHP+MYSQL原生開發(fā)可交付網(wǎng)站源代碼;符合網(wǎng)站優(yōu)化排名的后臺管理系統(tǒng)；做網(wǎng)站、網(wǎng)站建設(shè)收費合理；免費進(jìn)行網(wǎng)站備案等企業(yè)網(wǎng)站建設(shè)一條龍服務(wù).我們是一家持續(xù)穩(wěn)定運營了十多年的創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司。
今天碼仔沒有加班，早早的回到了寬敞且明亮的家里，剛一推開門就聽到女朋友的聲音：“飯在鍋里，我在床上。。。?！?/p>
叮鈴鈴。。。。
好吧，鬧鐘聲不僅打破了清晨的寧靜也打破了碼仔的美夢。。。程序員還想要女朋友?
但是!碼仔心里最不爽的是不僅沒有女朋友，每天還要跟不同的“對象”周旋。
程序員的世界里有這么一句話：”萬物皆對象“，我們每天都再跟各種”對象“打交道，每天用各種方法來處理“各對象”之間的關(guān)系。
碼仔就想了，為啥不能把工作中協(xié)調(diào)”對象“的方法用到自己身上呢?那樣自己是不是也能萬花從中過了?
說干就干，上方法!
只對自己的女朋友負(fù)責(zé) —— 單一責(zé)任鏈
首先在代碼界，單一責(zé)任鏈原則的定義是這樣的：單一職責(zé)原則(Single Responsibility Principle, SRP)：一個類只負(fù)責(zé)一個功能領(lǐng)域中的相應(yīng)職責(zé)，或者可以定義為：就一個類而言，應(yīng)該只有一個引起它變化的原因。它具有高內(nèi)聚，低耦合的特點。
也就是說，我們在設(shè)計類的時候，把實現(xiàn)某類功能的方法，合并到同一個類中，讓其只對單一功能負(fù)責(zé)，這樣可以很大程度的減少代碼耦合性。例如：我們封裝了一個圖片處理類用于處理代碼中所有圖片展示的問題，有圓角顯示圖片、圓形截取圖片、模糊圖片等等，到這里都是符合單一責(zé)任的原則，這個類只對圖片的顯示處理負(fù)責(zé)。但是如果我們再把圖片的下載、刪除等方法封裝進(jìn)來，這樣雖說類的功能更多了，但是其需要負(fù)的責(zé)任也多了，后期對其的維護(hù)和管理更麻煩了。
那這個原則應(yīng)該如何應(yīng)用到我們談對象中呢?其實是一樣的，單一責(zé)任，只對一個人負(fù)責(zé)任。我們只需要對自己的“對象”負(fù)責(zé)任就行了，別人的“對象”不需要你來負(fù)責(zé)任，你要強行對別人的“對象”負(fù)責(zé)任，那你大概率會打翻自己對象的醋壇子，然后強行搞崩你們之間脆弱的感情。
一諾千金 —— 開閉原則
我們先看一下開閉原則的定義：開閉原則(Open-Closed Principle, OCP)：一個軟件實體應(yīng)當(dāng)對擴展開放，對修改關(guān)閉。即軟件實體應(yīng)盡量在不修改原有代碼的情況下進(jìn)行擴展。也就是說，我們在維護(hù)和升級項目的時候，要盡量不去修改已經(jīng)寫好的代碼(除非是Bug)通過繼承或者別的方式去新增功能。那這個原則又如何運用到我們談對象當(dāng)中呢?
兩個人交往，肯定少不了一些保證、承諾什么的，對于這些東西一定要牢記，切不可修改。不讓會給人家不守信，不靠譜的感覺，當(dāng)你的女朋友對你有這種認(rèn)知的時候，那你們的感情大概率要涼了。
分清范圍 —— 里氏替換
什么是里氏替換原則呢：里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類(父類)的地方必須能透明地使用其子類的對象。就是說在軟件中將一個基類對象替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。這很顯然是通過繼承思想抽取的方法。那在生活中我們又怎樣通過這個方法好好跟對象交往呢?
陪對象一起吃飯也是個很麻煩的事情，因為她總有這些那些不吃的東西。有時候她會明確指出她不吃什么(蒜啊、菠菜啊)但是有時候她會給你一個范圍：不吃青菜。如果她給你說的是不吃菠菜，那么她也許會吃生菜或者其他青菜，但是如果她告訴你不吃青菜，你如果還是直男思想的給她吃生菜，還說：“你不是不吃青菜么?這是生菜不是青菜啊!”那你這個腦子還是不用談戀愛了。
以不變應(yīng)萬變 —— 依賴倒轉(zhuǎn)原則
我們先來認(rèn)識一下這個原則：依賴倒轉(zhuǎn)原則(Dependency Inversion Principle, DIP)：抽象不應(yīng)該依賴于細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依賴于抽象。換言之，要針對接口編程，而不是針對實現(xiàn)編程。依賴倒轉(zhuǎn)原則要求我們在程序代碼中傳遞參數(shù)時或在關(guān)聯(lián)關(guān)系中，盡量引用層次高的抽象層類，即使用接口和抽象類進(jìn)行變量類型聲明、參數(shù)類型聲明、方法返回類型聲明，以及數(shù)據(jù)類型的轉(zhuǎn)換等，而不要用具體類來做這些事情。而我們在實現(xiàn)依賴倒轉(zhuǎn)原則時，通常需要針對抽象層編程，將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當(dāng)一個對象要與其他對象發(fā)生依賴關(guān)系時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分別是：構(gòu)造注入，設(shè)值注入(Setter注入)和接口注入。(依賴注入不僅解耦，還方便單元測試)
戀愛中給女朋友買東西是很麻煩的一件事，因為女人都是善變的。前一秒她還給你說她喜歡這個顏色的口紅，下一秒可能就變成了另一個顏色的包包。所以戀愛的時候與其猜來猜去，不如一步到位，直接給錢，以不變應(yīng)萬變，想買什么買什么，方便還省事。(哎!可憐的碼仔，為了性福生活只能不斷搬磚了)
對癥下藥——接口隔離原則
這個原則的定義是這樣的：接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應(yīng)該依賴那些它不需要的接口。
接口隔離原則與單一職責(zé)原則都是對接口設(shè)計的規(guī)范。不過，單一職責(zé)原則強調(diào)的是職責(zé)的單一，即業(yè)務(wù)劃分上的單一;接口隔離原則強調(diào)的是具體實現(xiàn)時，接口的規(guī)模不能過大。比如，一個接口的設(shè)計符合單一職責(zé)原則，只包含一個職責(zé)的定義，但是實現(xiàn)這個職責(zé)需要較多的函數(shù)或方法，而并不是所有的模塊使用此接口時都會用到所有的方法，那么這個接口的設(shè)計就不符合接口隔離原則。
不僅在編程中需要接口隔離，談對象同樣也需要 。廣大男同胞肯定都有一個通病：對象給你說不舒服，你回復(fù)“多喝熱水”;對象給你說感冒了，你回復(fù)“多喝熱水”;對象給你說無聊了，你回復(fù)“多喝熱水" …… 熱水治百病。這樣我肯定你活不過三秒。什么藥治什么病，對癥下藥才是王道。
不要到處沾花惹草——迪米特法則
最后一個原則，迪米特法則(Law of Demeter, LoD)：一個軟件實體應(yīng)當(dāng)盡可能少地與其他實體發(fā)生相互作用。迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對于一個對象，其朋友包括以下幾類：
(1)當(dāng)前對象本身(this);(2)以參數(shù)形式傳入到當(dāng)前對象方法中的對象;(3)當(dāng)前對象的成員對象;(4)如果當(dāng)前對象的成員對象是一個集合，那么集合中的元素也都是朋友;(5)當(dāng)前對象所創(chuàng)建的對象。
任何一個對象，如果滿足上面的條件之一，就是當(dāng)前對象的“朋友”，否則就是“陌生人”。在應(yīng)用迪米特法則時，一個對象只能與直接朋友發(fā)生交互，不要與“陌生人”發(fā)生直接交互，這樣做可以降低系統(tǒng)的耦合度，一個對象的改變不會給太多其他對象帶來影響。
”不要和陌生人說話“，都有對象了還出去沾花惹草肯定是不行的了，畢竟兩人戀愛要相互坦誠。只有一心一意想著對方，兩人的感情才能長長久久。
總結(jié)
以上便是面向“對象”的六大原則。熟練掌握這六大原則不僅能讓我們在物質(zhì)層面更好的滿足“對象”(代碼都寫好了，鈔票還遠(yuǎn)嗎?)，還能讓“對象”在精神層面滿足自己(對象都哄開心了，你離開心還遠(yuǎn)嗎?)。所以無論是為了我們的幸福生活，還是為了我們的性福生活，我們都有必要學(xué)習(xí)好面向?qū)ο蟆＜佑桶?騷年
分享名稱：討好女朋友的6大技巧
URL鏈接：http://m.fisionsoft.com.cn/article/cosedhh.html
