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