程序員，四步教你寫(xiě)出簡(jiǎn)單易懂的代碼！
網(wǎng)站建設
發(fā)布者：cya
2019-12-05 08:57
訪(fǎng)問(wèn)量：87
日常工作過(guò)程中，為了提升處理事情的效率，我們喜歡化繁為簡(jiǎn)。那如何培養出良好的思維模式快速“套出”代碼呢？今天，我們將用OOP模式作為作為范例，為大家提供借鑒的思維模板。說(shuō)起編程，我的目標是編寫(xiě)簡(jiǎn)單易懂的代碼。也就是 Bob Martin所說(shuō)的干凈的代碼。也有人稱(chēng)之為可讀或可維護的代碼。其實(shí)，這眾多說(shuō)法指的都是同一件事。
編寫(xiě)簡(jiǎn)單易懂的代碼需要周全的考慮。需要通過(guò)不斷的重構，寫(xiě)出正確的代碼。通常還需要同事的審核或結對編程。但是，我通過(guò)多年的職業(yè)生涯總結出了一些模式，這些模式可以幫助我編寫(xiě)簡(jiǎn)單易懂的代碼。雖然這些模式不一定會(huì )加快寫(xiě)代碼的速度，也不一定會(huì )降低寫(xiě)代碼的難度，但是可以幫助我寫(xiě)出更簡(jiǎn)單的代碼。每當面臨新的問(wèn)題時(shí)，我都會(huì )采用這些模式，將問(wèn)題化繁為簡(jiǎn)。簡(jiǎn)單地介紹一下，我所說(shuō)的模式指的是你可能有所耳聞的OOP模式。我知道從很多方面來(lái)說(shuō)OOP已經(jīng)過(guò)時(shí)了，但無(wú)論你喜歡哪種范式，這些模式仍然很實(shí)用。在這些模式中，簡(jiǎn)單的組合重于繼承——繼承恰恰是大多數人討厭OOP的原因。本文中提到的大多數模式都源自“四人幫”的著(zhù)作《設計模式》我將在本文中簡(jiǎn)要介紹每種模式，有關(guān)詳細內容我強烈推薦你閱讀這本書(shū)。
“四人幫”Gang of Four，指Erich Gamma、Richard Helm、Ralph Johnson以及John Vlissides四人。
工廠(chǎng)（Factory ）本質(zhì)上是一個(gè)對象，其唯一的工作就是生成其他對象。工廠(chǎng)能夠以不同的方式呈現，但我認為抽象工廠(chǎng)模式非常強大。抽象工廠(chǎng)不僅允許你在運行時(shí)更改已生成或已構建的對象，還可以在運行時(shí)更改工廠(chǎng)。雖然聽(tīng)起來(lái)有點(diǎn)迷糊，但是對于Spring或Unity等控制反轉框架來(lái)說(shuō)，它確實(shí)非常有效。接口Factory <T> { T build（Metadata d）} 類(lèi)ClientFactory實(shí)現Factory <Client> { Client build（Metadata d）{
//構建實(shí)際對象并返回
} }
每當我需要構建一個(gè)具體的對象，而且這個(gè)對象能夠根據配置與簡(jiǎn)單的接口相匹配時(shí)，我都會(huì )嘗試使用抽象工廠(chǎng)，并且我不希望使用該對象的其他所有類(lèi)知曉該對象的變化。這句話(huà)雖然很長(cháng)，但核心思想符合其他軟件工程原理的經(jīng)典思想：即隱藏信息，一個(gè)類(lèi)只做一件事，以及小接口。更直接地說(shuō)，抽象工廠(chǎng)有助于隱藏對象的繁瑣工作。
我敢說(shuō)，我們所有人都遇到過(guò)這樣的項目（無(wú)論是否是編程的工作）：我們將某方面的工作委托給其他人，而不是親歷親為。通常我們對項目進(jìn)行進(jìn)一步“升級”的時(shí)候，就會(huì )采用委托模式：項目協(xié)調人可能會(huì )將工作委托給一組助理，然后由他們將工作委托給自愿擔任領(lǐng)導的人等。代碼中的委托模式也完全相同：高階類(lèi)要求低階類(lèi)為它們工作。這有助于保持高階類(lèi)的簡(jiǎn)單性，并減少對其下層結構的了解。接口Validator {
bool validate（Object o）} 類(lèi)ValidatorHelper實(shí)現Validator { Set <Validator>委托；
bool validate（Object o）{
for（Validator v：委托）{
如果（！v.validate（o））返回false
}
返回true
} } 類(lèi)RestController { ValidationHelper helper; 響應addObject（Object o）{
如果（helper.validate（o））返回ErrorResponse
} }
我發(fā)現委托模式可用于驗證、排序、規范化等操作。常見(jiàn)的使用可能要視特定的數據形式而定，但做出有關(guān)數據決策的類(lèi)不再需要完整地了解委托工作的細枝末節，它只需要知道工作已經(jīng)完成。在所有改變了我寫(xiě)代碼方式的模式中，建造模式當屬第一。從一開(kāi)始我就用建造編寫(xiě)每個(gè)DTO（data transfer objects，數據傳輸對象）。生成器不需要大量的實(shí)際工作即可生成靈活且可擴展的代碼，此外它們還具有不可變的好處！其他語(yǔ)言可能沒(méi)有（甚至不需要）建造模式，因為它們的構造器中擁有命名參數，且帶有合理的默認值。從本質(zhì)上講，這是一碼事：只聲明需要設置成特定值的東西，而不必擔心其他內容。類(lèi)Dto { 字符串s
int我私有Dto（String s，int i）{
this.s = s
this.i = i
} public DtoBuilder builder（）{
return new DtoBuilder（）
} 公共靜態(tài)類(lèi)DtoBuilder {
private String s =“一些字符串“
private int i = 0 public DtoBuilder withString（String s）{
this.s = s
return this
} public DtoBuilder withInt（int it）{
this.i =我
返回此
} public Dto build（）{
返回新的Dto（ s，i）
}
} }
注意：在Java中，我們也使用Lombok處理所有的繁瑣代碼。這種模式之所以可以讓我的代碼變得如此簡(jiǎn)單，原因是當所有對象都使用一個(gè)生成器時(shí)，就可以自動(dòng)化新對象的生成。在我們的代碼庫中，我們總會(huì )向需要構建的類(lèi)添加一個(gè)靜態(tài)工廠(chǎng)方法，以返回生成器。之后，我們只需遵循流暢的API鏈，傳入變量，然后鍵入.build()。僅此而已。你無(wú)需花時(shí)間研究構造函數。你甚至不需要查看建造代碼。你可以在寫(xiě)代碼的時(shí)候隨時(shí)使用?，F代IDE中的自動(dòng)補齊功能可以告訴你哪些變量。非常簡(jiǎn)單。《設計模式》中沒(méi)有提及這種模式，但它與責任鏈和模板方法的關(guān)系最密切。在這種模式下，每個(gè)“鏈”都可以增強或擴充一個(gè)對象，并將增強后的對象返回給調用者。它可以對鏈中的每個(gè)增強器都進(jìn)行這種操作，而鏈也可以決定在需要時(shí)跳過(guò)鏈的其余部分。你可能會(huì )認為這種做法會(huì )違反“干凈的代碼”中有關(guān)函數副作用的規則。而我認為這并沒(méi)有違反這些原則的原因在于，增強器必須將增強后的對象返回給調用者，因此在很多時(shí)候，它只是在聲明對象可能會(huì )變化。調用者都知道，它可能是一個(gè)新對象（尤其是在不可變約束的情況下）。接口Enricher <T> { T rich（T something）; } 類(lèi)HeadersEnricher實(shí)現Enricher <Headers> {
標頭
rich（Headers標頭）{ headers.add（“ x-header”，“某物”）
返回標頭
} }
我發(fā)現當你需要用新?tīng)顟B(tài)增強一個(gè)對象時(shí)，這種模式尤其管用。例如，如果你有一個(gè)來(lái)自Kafka流的對象，需要將一些數據添加到數據庫中，然后再保存到數據倉庫中，那么就可以考慮增強器模式。
以上這些只是我在編寫(xiě)簡(jiǎn)單易懂的代碼時(shí)，最喜歡的一部分模式。我無(wú)法在一篇文章中介紹日常編程工作中使用的所有模式。希望通過(guò)本文的介紹為你的編程工具錦上添花。https://levelup.gitconnected.com/my-top-4-patterns-for-writing-simple-code-466705ac0b97
網(wǎng)站建好之后會(huì )有影響嗎？