了解這些軟件設(shè)計思想，你的思維至少上升一個段位
本文轉(zhuǎn)載自微信公眾號「Java極客技術(shù)」，作者鴨血粉絲。轉(zhuǎn)載本文請聯(lián)系Java極客技術(shù)公眾號。
一、介紹
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名為 Design Patterns - Elements of Reusable Object-Oriented Software(中文譯名：設(shè)計模式 - 可復(fù)用的面向?qū)ο筌浖? 的書，該書首次提到了軟件開發(fā)中設(shè)計模式的概念，四位作者合稱 GOF(全拼 Gang of Four)，簡稱四人幫!
書中共說到 23 種設(shè)計模式，這些模式可以分為三大類：創(chuàng)建型模式(Creational Patterns)、結(jié)構(gòu)型模式(Structural Patterns)、行為型模式(Behavioral Patterns)。
當(dāng)然，隨著軟件的快速發(fā)展，還出現(xiàn)另一類我們所熟知的設(shè)計模式：J2EE 設(shè)計模式。
首先要跟大家說明的是，設(shè)計模式其實不是一項新技術(shù)，而是眾多軟件開發(fā)人員經(jīng)過相當(dāng)長的一段時間的試用和試錯總結(jié)出來的一套軟件設(shè)計開發(fā)實踐方案，學(xué)習(xí)這些知識有助于經(jīng)驗不足的開發(fā)人員通過一種簡單快捷的方式來學(xué)習(xí)軟件設(shè)計。
也不BB了，下面我們就一起來深入了解一下大神們總結(jié)的這套方法論!
二、方法論
2.1、單一職責(zé)原則
單一職責(zé)原則，顧名思義，一個類負(fù)責(zé)一個功能的處理，比如我們在代碼中經(jīng)常會涉及到調(diào)用第三方的接口，通常我們往往會將一個接口請求方法封裝成一個http請求的工具類，這樣其他的調(diào)用方能非常方便的進(jìn)行調(diào)用。
單一職責(zé)原則，主要的目的是將一個功能劃分到合適的粒度，讓這些各自執(zhí)行單一職責(zé)的類，各司其職。
還有我們常常說的mvc模式，將數(shù)據(jù)操作與業(yè)務(wù)邏輯處理進(jìn)行分離，也是屬于單一職責(zé)原則的一種。
2.2、開閉原則
開閉原則，指的是：對擴(kuò)展開放，對修改關(guān)閉。
這里的意思是在增加新功能的時候，能不改代碼就盡量不要改，如果只增加代碼就完成了新功能，那是最好的。
下面我舉個簡單的例子，大家可能就懂了。
在實際的項目開發(fā)過程中，尤其是與第三方公司進(jìn)行接口對接的時候，例如 a 公司，他的接口協(xié)議要求采用rsa加密;b 公司，他的接口協(xié)議采用aes加密，c公司，他的接口協(xié)議要求采用md5就可以了...
在一開始的時候，可能你沒有想那么多，設(shè)想所有其他公司跟你對接的時候，全部采用rsa加密，那么當(dāng)?shù)诙夜緛砹藭r候，要求采用aes，這個時候，你必須得改代碼才能支持這種功能，假如又來了其他公司呢?
在這種情況下，我們可以采用面向接口編程的思想，定義一個抽象的方法，然后針對不同的加密算法，編寫不同的實現(xiàn)類，當(dāng)新來了一家公司要求采用不同的加密算法時，我們只需要擴(kuò)展一個新的實現(xiàn)類，在邏輯處理層進(jìn)行路由即可快速完成開發(fā)和對接!
實現(xiàn)開閉原則的主要步驟就是將業(yè)務(wù)方法里面的邏輯進(jìn)行抽象化，從而實現(xiàn)邏輯層面代碼的解耦。
2.3、里氏代換原則
里氏替換原則，通俗的說就是：子類可以擴(kuò)展父類的功能，但不能改變父類原有的功能。
也就是說：子類繼承父類時，除添加新的方法完成新增功能外，盡量不要重寫父類的方法。
當(dāng)子類在重寫父類的方法時，如果使用不當(dāng)，很可能會改變父類方法中的邏輯語義，進(jìn)而造成邏輯處理混亂。
在實際的業(yè)務(wù)開發(fā)中，尤其是大家在使用類繼承操作時，應(yīng)當(dāng)謹(jǐn)慎重新父類方法，方法定義的時候，名稱也盡量不要發(fā)生重名。
同時，應(yīng)該注意類過多的繼承，例如 A 類繼承自 B 類，B 類 繼承自 C 類，C 類繼承 D 類，這種場景下，第一：邏輯很可能非常復(fù)雜，代碼可讀性可能很差，第二種可能會出現(xiàn)方法名或者屬性名沖突。
我曾經(jīng)修改一個老項目 bug 的時候，就出現(xiàn)過這種情況，一個實體類出現(xiàn)三層關(guān)系的繼承，當(dāng)我把子類進(jìn)行序列化成json的時候，突然報錯，原因就是因為里面有個屬性，在基類里面也定義了，但是類型卻不一樣，也就是說在這個子類里面有兩個相同的屬性，只是字段類型不同而已，從而導(dǎo)致這個序列化報錯。
因此，大家在使用類繼承操作時，一定要謹(jǐn)慎處理，最好的情況下是一層關(guān)系繼承，這樣即使出現(xiàn)問題了，也好排查，范圍可控;繼承關(guān)系多了，反而代碼變的非常復(fù)雜，每個方法邏輯都需要一一梳理清楚，你才敢去下手，這種情況下，反而為難了自己!
2.4、依賴倒轉(zhuǎn)原則
依賴倒轉(zhuǎn)原則，簡單的說就是面向接口編程，依賴于抽象而不依賴于具體，他是實現(xiàn)開閉原則的一個途徑。
依賴倒轉(zhuǎn)原則主要有以下幾點：
- 高層的模塊不應(yīng)該依賴于低層的模塊，這兩者都應(yīng)該依賴于其抽象
- 抽象不應(yīng)該依賴細(xì)節(jié)
- 細(xì)節(jié)應(yīng)該依賴抽象
換句話說，就是將具體類里面的方法進(jìn)行邏輯抽象化，提升到接口或者抽象類里面，由具體的實現(xiàn)類去實現(xiàn)具體的業(yè)務(wù)邏輯，抽象層不關(guān)注細(xì)節(jié)。
也就是我們俗稱的，不管遇到啥事情，先看大局，在看小點。
舉個例子，例如我們常常使用的MVC框架，在Service層通常會先編寫接口類，然后在編寫服務(wù)實現(xiàn)類，這就是典型的面向接口編程，這種方案有哪些好處呢?
- 可以減少研發(fā)人員并行開發(fā)引起的風(fēng)險
- 可以顯著提高代碼的可讀性和可維護(hù)性
- 可以降低類間的耦合性
當(dāng)一個大項目開發(fā)的時候，試想一下，如果2個以上研發(fā)人員在編寫同一個類的同一個方法，沒有定義接口的情況下，隨著時間的流逝，這個類大概率會非?；靵y，同時，里面的方法估計閱讀起來也很困難，一眼望去基本上不知道這個方法是干嘛的，尤其是重載方法很多的時候，尤其困難。
當(dāng)我們引入接口之后，將所有的核心方法全部抽象定義，當(dāng)我們對其進(jìn)行二次開發(fā)的時，也會能快速定位到以前的和諧方法，然后進(jìn)行快速定位和維護(hù)。
面向接口編程，還有一個很大的好處，就是可以降低類之間的耦合度。
2.5、接口隔離原則
接口隔離原則的意思是：盡量將一個接口拆的更細(xì)，使用多個隔離的接口，比使用單個接口要好。
這個原則基本上是從大型軟件架構(gòu)出發(fā)、便于升級和維護(hù)的思想誕生出來的。
比如，一個第三方保險服務(wù)系統(tǒng)里面，如果是小項目，你可以在一個接口里面定義投保方法、取消方法、 退保方法、 理賠方法、 保單方法這5種方法。
當(dāng)你只跟一家保險公司合作的時候，這套接口定義是沒問題的，但是假如現(xiàn)在公司的業(yè)務(wù)發(fā)展的非?？?，已經(jīng)引入10幾家保險公司了，你會發(fā)現(xiàn)這個接口基本上頂不住了，在此有兩種方法可以解決這種技術(shù)難題：
- 1、針對不同的保險公司，又重新定義一個接口，然后還是里面的5種方法
- 2、針對不同的操作行為，比如投保，單獨定義一套接口，然后針對不同的保險公司編寫不同的實現(xiàn)類
這兩種其實本質(zhì)都是將一個接口，拆成多個顆粒度更細(xì)的接口，然后從行為上，讓各種的實現(xiàn)類更加獨立，進(jìn)而降低類之間的耦合度，開發(fā)起來層次清晰，有利于系統(tǒng)的穩(wěn)定!
2.6、組合/聚合復(fù)用原則
合成復(fù)用原則的意思就是：盡量使用組合/聚合的方式，而不是使用繼承。
所謂組合/聚合的方式，其實就是我們在springMVC里面使用的ioc依賴注入方式，
- @Component
- public class AService {
- /**
- * ioc依賴注入
- */
- @Autowired
- private BService bService;
- //業(yè)務(wù)代碼...
- }
AService類調(diào)用BService類，有兩種方式可以實現(xiàn)，第一種就是通過繼承方式，可以直接調(diào)用;第二種方式就是通過ioc依賴注入的方式，在類里面進(jìn)行組合操作，然后進(jìn)行調(diào)用。
很明顯，第二種方式，我們使用的愛不釋手!
這種方式有個好處就是，代碼層次清晰，編寫優(yōu)雅，用上之后容易上癮，推薦使用!
2.7、迪米特法則
迪米特法則，又稱最少知道原則，意思就是說：一個實體應(yīng)當(dāng)盡量少地與其他實體之間發(fā)生相互作用，使得系統(tǒng)功能模塊相對獨立。
類似單一原則的思想，例如我們編寫實體類的時候，基本上就是屬性名稱，加get/set。
- public class User {
- /**
- * 用戶id
- */
- private Long userId;
- /**
- * 用戶姓名
- */
- private String userName;
- public Long getUserId(){
- return this.userId;
- }
- public void setUserId(Long userId){
- this.userId = userId;
- }
- public String getUserName(){
- return this.userName;
- }
- public void setUserName(String userName){
- this.userName = userName;
- }
- }
當(dāng)一個實體里面出現(xiàn)跟自己沒太大關(guān)系的代碼時，例如數(shù)據(jù)運算邏輯處理，這個時候應(yīng)當(dāng)將這部分代碼全部清理出去，交由業(yè)務(wù)處理層來出來。
從實體類的定義來說，它主要的功能就是承擔(dān)數(shù)據(jù)展示，當(dāng)多個業(yè)務(wù)處理層在使用這個實體類的時候，如果你們嵌套了很多的數(shù)據(jù)運算邏輯，可能在返回的時候，客戶端得到的實體類的屬性值，并不是正確的結(jié)果!
三、小結(jié)
上面一共介紹了 7 種設(shè)計原則，基本上都是大神們經(jīng)過很多次血的教訓(xùn)，總結(jié)出來的一套方法論。
這些設(shè)計原則，可以給同行在實際的軟件設(shè)計過程中，提供一些思路，具體的應(yīng)用，還需要結(jié)合實際的業(yè)務(wù)場景進(jìn)一步思考，怎么讓系統(tǒng)變的更加可靠，開發(fā)更佳迅速，代碼閱讀起來更佳輕松，關(guān)鍵在于靈活運用!
