日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間:8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
一文聊透軟件設(shè)計(jì)模式這件事兒

在實(shí)際的軟件編程過(guò)程中,代碼設(shè)計(jì)的合理性會(huì)直接決定項(xiàng)目的開(kāi)發(fā)復(fù)雜程度,一個(gè)好的設(shè)計(jì)模型,會(huì)讓你的軟件開(kāi)發(fā)過(guò)程順暢無(wú)比!

一、介紹

在 1994 年,由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名為 Design Patterns - Elements of Reusable Object-Oriented Software(中文譯名:設(shè)計(jì)模式 - 可復(fù)用的面向?qū)ο筌浖? 的書(shū),該書(shū)首次提到了軟件開(kāi)發(fā)中設(shè)計(jì)模式的概念,四位作者合稱 GOF(全拼 Gang of Four),簡(jiǎn)稱四人幫!

書(shū)中共說(shuō)到 23 種設(shè)計(jì)模式,這些模式可以分為三大類:創(chuàng)建型模式(Creational Patterns)、結(jié)構(gòu)型模式(Structural Patterns)、行為型模式(Behavioral Patterns)。

當(dāng)然,隨著軟件的快速發(fā)展,還出現(xiàn)另一類我們所熟知的設(shè)計(jì)模式:J2EE 設(shè)計(jì)模式。

首先要跟大家說(shuō)明的是,設(shè)計(jì)模式其實(shí)不是一項(xiàng)新技術(shù),而是眾多軟件開(kāi)發(fā)人員經(jīng)過(guò)相當(dāng)長(zhǎng)的一段時(shí)間的試用和試錯(cuò)總結(jié)出來(lái)的一套軟件設(shè)計(jì)開(kāi)發(fā)實(shí)踐方案,學(xué)習(xí)這些知識(shí)有助于經(jīng)驗(yàn)不足的開(kāi)發(fā)人員通過(guò)一種簡(jiǎn)單快捷的方式來(lái)學(xué)習(xí)軟件設(shè)計(jì)。

也不BB了,下面我們就一起來(lái)深入了解一下大神們總結(jié)的這套方法論!

二、方法論

2.1、單一職責(zé)原則

單一職責(zé)原則,顧名思義,一個(gè)類負(fù)責(zé)一個(gè)功能的處理,比如我們?cè)诖a中經(jīng)常會(huì)涉及到調(diào)用第三方的接口,通常我們往往會(huì)將一個(gè)接口請(qǐng)求方法封裝成一個(gè)http請(qǐng)求的工具類,這樣其他的調(diào)用方能非常方便的進(jìn)行調(diào)用。

單一職責(zé)原則,主要的目的是將一個(gè)功能劃分到合適的粒度,讓這些各自執(zhí)行單一職責(zé)的類,各司其職。

還有我們常常說(shuō)的mvc模式,將數(shù)據(jù)操作與業(yè)務(wù)邏輯處理進(jìn)行分離,也是屬于單一職責(zé)原則的一種。

2.2、開(kāi)閉原則

開(kāi)閉原則,指的是:對(duì)擴(kuò)展開(kāi)放,對(duì)修改關(guān)閉。

這里的意思是在增加新功能的時(shí)候,能不改代碼就盡量不要改,如果只增加代碼就完成了新功能,那是最好的。

下面我舉個(gè)簡(jiǎn)單的例子,大家可能就懂了。

在實(shí)際的項(xiàng)目開(kāi)發(fā)過(guò)程中,尤其是與第三方公司進(jìn)行接口對(duì)接的時(shí)候,例如 a 公司,他的接口協(xié)議要求采用rsa加密;b 公司,他的接口協(xié)議采用aes加密,c公司,他的接口協(xié)議要求采用md5就可以了...

在一開(kāi)始的時(shí)候,可能你沒(méi)有想那么多,設(shè)想所有其他公司跟你對(duì)接的時(shí)候,全部采用rsa加密,那么當(dāng)?shù)诙夜緛?lái)了時(shí)候,要求采用aes,這個(gè)時(shí)候,你必須得改代碼才能支持這種功能,假如又來(lái)了其他公司呢?

在這種情況下,我們可以采用面向接口編程的思想,定義一個(gè)抽象的方法,然后針對(duì)不同的加密算法,編寫(xiě)不同的實(shí)現(xiàn)類,當(dāng)新來(lái)了一家公司要求采用不同的加密算法時(shí),我們只需要擴(kuò)展一個(gè)新的實(shí)現(xiàn)類,在邏輯處理層進(jìn)行路由即可快速完成開(kāi)發(fā)和對(duì)接!

實(shí)現(xiàn)開(kāi)閉原則的主要步驟就是將業(yè)務(wù)方法里面的邏輯進(jìn)行抽象化,從而實(shí)現(xiàn)邏輯層面代碼的解耦。

2.3、里氏代換原則

里氏替換原則,通俗的說(shuō)就是:子類可以擴(kuò)展父類的功能,但不能改變父類原有的功能。

也就是說(shuō):子類繼承父類時(shí),除添加新的方法完成新增功能外,盡量不要重寫(xiě)父類的方法。

當(dāng)子類在重寫(xiě)父類的方法時(shí),如果使用不當(dāng),很可能會(huì)改變父類方法中的邏輯語(yǔ)義,進(jìn)而造成邏輯處理混亂。

在實(shí)際的業(yè)務(wù)開(kāi)發(fā)中,尤其是大家在使用類繼承操作時(shí),應(yīng)當(dāng)謹(jǐn)慎重新父類方法,方法定義的時(shí)候,名稱也盡量不要發(fā)生重名。

同時(shí),應(yīng)該注意類過(guò)多的繼承,例如 A 類繼承自 B 類,B 類 繼承自 C 類,C 類繼承 D 類,這種場(chǎng)景下,第一:邏輯很可能非常復(fù)雜,代碼可讀性可能很差,第二種可能會(huì)出現(xiàn)方法名或者屬性名沖突。

我曾經(jīng)修改一個(gè)老項(xiàng)目 bug 的時(shí)候,就出現(xiàn)過(guò)這種情況,一個(gè)實(shí)體類出現(xiàn)三層關(guān)系的繼承,當(dāng)我把子類進(jìn)行序列化成json的時(shí)候,突然報(bào)錯(cuò),原因就是因?yàn)槔锩嬗袀€(gè)屬性,在基類里面也定義了,但是類型卻不一樣,也就是說(shuō)在這個(gè)子類里面有兩個(gè)相同的屬性,只是字段類型不同而已,從而導(dǎo)致這個(gè)序列化報(bào)錯(cuò)。

因此,大家在使用類繼承操作時(shí),一定要謹(jǐn)慎處理,最好的情況下是一層關(guān)系繼承,這樣即使出現(xiàn)問(wèn)題了,也好排查,范圍可控;繼承關(guān)系多了,反而代碼變的非常復(fù)雜,每個(gè)方法邏輯都需要一一梳理清楚,你才敢去下手,這種情況下,反而為難了自己!

2.4、依賴倒轉(zhuǎn)原則

依賴倒轉(zhuǎn)原則,簡(jiǎn)單的說(shuō)就是面向接口編程,依賴于抽象而不依賴于具體,他是實(shí)現(xiàn)開(kāi)閉原則的一個(gè)途徑。

依賴倒轉(zhuǎn)原則主要有以下幾點(diǎn):

  • 高層的模塊不應(yīng)該依賴于低層的模塊,這兩者都應(yīng)該依賴于其抽象
  • 抽象不應(yīng)該依賴細(xì)節(jié)
  • 細(xì)節(jié)應(yīng)該依賴抽象

換句話說(shuō),就是將具體類里面的方法進(jìn)行邏輯抽象化,提升到接口或者抽象類里面,由具體的實(shí)現(xiàn)類去實(shí)現(xiàn)具體的業(yè)務(wù)邏輯,抽象層不關(guān)注細(xì)節(jié)。

也就是我們俗稱的,不管遇到啥事情,先看大局,在看小點(diǎn)。

舉個(gè)例子,例如我們常常使用的MVC框架,在Service層通常會(huì)先編寫(xiě)接口類,然后在編寫(xiě)服務(wù)實(shí)現(xiàn)類,這就是典型的面向接口編程,這種方案有哪些好處呢?

  • 可以減少研發(fā)人員并行開(kāi)發(fā)引起的風(fēng)險(xiǎn)
  • 可以顯著提高代碼的可讀性和可維護(hù)性
  • 可以降低類間的耦合性

當(dāng)一個(gè)大項(xiàng)目開(kāi)發(fā)的時(shí)候,試想一下,如果2個(gè)以上研發(fā)人員在編寫(xiě)同一個(gè)類的同一個(gè)方法,沒(méi)有定義接口的情況下,隨著時(shí)間的流逝,這個(gè)類大概率會(huì)非?;靵y,同時(shí),里面的方法估計(jì)閱讀起來(lái)也很困難,一眼望去基本上不知道這個(gè)方法是干嘛的,尤其是重載方法很多的時(shí)候,尤其困難。

當(dāng)我們引入接口之后,將所有的核心方法全部抽象定義,當(dāng)我們對(duì)其進(jìn)行二次開(kāi)發(fā)的時(shí),也會(huì)能快速定位到以前的和諧方法,然后進(jìn)行快速定位和維護(hù)。

面向接口編程,還有一個(gè)很大的好處,就是可以降低類之間的耦合度。

2.5、接口隔離原則

接口隔離原則的意思是:盡量將一個(gè)接口拆的更細(xì),使用多個(gè)隔離的接口,比使用單個(gè)接口要好。

這個(gè)原則基本上是從大型軟件架構(gòu)出發(fā)、便于升級(jí)和維護(hù)的思想誕生出來(lái)的。

比如,一個(gè)第三方保險(xiǎn)服務(wù)系統(tǒng)里面,如果是小項(xiàng)目,你可以在一個(gè)接口里面定義投保方法、取消方法、 退保方法、 理賠方法、 保單方法這5種方法。

當(dāng)你只跟一家保險(xiǎn)公司合作的時(shí)候,這套接口定義是沒(méi)問(wèn)題的,但是假如現(xiàn)在公司的業(yè)務(wù)發(fā)展的非??欤呀?jīng)引入10幾家保險(xiǎn)公司了,你會(huì)發(fā)現(xiàn)這個(gè)接口基本上頂不住了,在此有兩種方法可以解決這種技術(shù)難題:

  • 針對(duì)不同的保險(xiǎn)公司,又重新定義一個(gè)接口,然后還是里面的5種方法
  • 針對(duì)不同的操作行為,比如投保,單獨(dú)定義一套接口,然后針對(duì)不同的保險(xiǎn)公司編寫(xiě)不同的實(shí)現(xiàn)類

這兩種其實(shí)本質(zhì)都是將一個(gè)接口,拆成多個(gè)顆粒度更細(xì)的接口,然后從行為上,讓各種的實(shí)現(xiàn)類更加獨(dú)立,進(jìn)而降低類之間的耦合度,開(kāi)發(fā)起來(lái)層次清晰,有利于系統(tǒng)的穩(wěn)定!

2.6、組合/聚合復(fù)用原則

合成復(fù)用原則的意思就是:盡量使用組合/聚合的方式,而不是使用繼承。

所謂組合/聚合的方式,其實(shí)就是我們?cè)趕pringMVC里面使用的ioc依賴注入方式,

@Component
public class AService {

/**
* ioc依賴注入
*/
@Autowired
private BService bService;

//業(yè)務(wù)代碼...
}

AService類調(diào)用BService類,有兩種方式可以實(shí)現(xiàn),第一種就是通過(guò)繼承方式,可以直接調(diào)用;第二種方式就是通過(guò)ioc依賴注入的方式,在類里面進(jìn)行組合操作,然后進(jìn)行調(diào)用。

很明顯,第二種方式,我們使用的愛(ài)不釋手!

這種方式有個(gè)好處就是,代碼層次清晰,編寫(xiě)優(yōu)雅,用上之后容易上癮,推薦使用!

2.7、迪米特法則

迪米特法則,又稱最少知道原則,意思就是說(shuō):一個(gè)實(shí)體應(yīng)當(dāng)盡量少地與其他實(shí)體之間發(fā)生相互作用,使得系統(tǒng)功能模塊相對(duì)獨(dú)立。

類似單一原則的思想,例如我們編寫(xiě)實(shí)體類的時(shí)候,基本上就是屬性名稱,加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)一個(gè)實(shí)體里面出現(xiàn)跟自己沒(méi)太大關(guān)系的代碼時(shí),例如數(shù)據(jù)運(yùn)算邏輯處理,這個(gè)時(shí)候應(yīng)當(dāng)將這部分代碼全部清理出去,交由業(yè)務(wù)處理層來(lái)出來(lái)。

從實(shí)體類的定義來(lái)說(shuō),它主要的功能就是承擔(dān)數(shù)據(jù)展示,當(dāng)多個(gè)業(yè)務(wù)處理層在使用這個(gè)實(shí)體類的時(shí)候,如果你們嵌套了很多的數(shù)據(jù)運(yùn)算邏輯,可能在返回的時(shí)候,客戶端得到的實(shí)體類的屬性值,并不是正確的結(jié)果!

三、小結(jié)

上面一共介紹了 7 種設(shè)計(jì)原則,基本上都是大神們經(jīng)過(guò)很多次血的教訓(xùn),總結(jié)出來(lái)的一套方法論。

這些設(shè)計(jì)原則,可以給同行在實(shí)際的軟件設(shè)計(jì)過(guò)程中,提供一些思路,具體的應(yīng)用,還需要結(jié)合實(shí)際的業(yè)務(wù)場(chǎng)景進(jìn)一步思考,怎么讓系統(tǒng)變的更加可靠,開(kāi)發(fā)更佳迅速,代碼閱讀起來(lái)更佳輕松,關(guān)鍵在于靈活運(yùn)用!


網(wǎng)站欄目:一文聊透軟件設(shè)計(jì)模式這件事兒
標(biāo)題鏈接:http://www.5511xx.com/article/coesgjc.html