本文基于對(duì)一般編程習(xí)慣的一些個(gè)人見(jiàn)解，并不涉及方法論層面. 但是，只要經(jīng)驗(yàn)豐富且實(shí)用，它也可能會(huì)吸引許多不同的觀點(diǎn). 讓我們從熟悉的界面編程開(kāi)始

在最初的軟件設(shè)計(jì)中，接口編程的概念似乎是宇宙的真相（在軟件世界中沒(méi)有真相部門(mén)），對(duì)此的解釋是

具體類包含實(shí)現(xiàn)細(xì)節(jié)，而抽象類僅表示概念

當(dāng)然非常合理和權(quán)威.

但是界面的前提是什么？在設(shè)計(jì)與外部系統(tǒng)交互的API的情況下. 例如，如果您想向外界提供用戶注冊(cè)界面，則可以在該界面上共同同意

無(wú)效寄存器（字符串用戶名，字符串密碼）拋出RegistrationException;

并且此接口應(yīng)該是穩(wěn)定的，然后每個(gè)實(shí)現(xiàn)或完成呼叫細(xì)節(jié)，即使實(shí)現(xiàn)未完成，也可以通過(guò)Mock對(duì)呼叫端進(jìn)行單元測(cè)試.

但是，在實(shí)踐中，對(duì)面向接口編程的理解很容易成為任何非工具類. 數(shù)據(jù)類首先聲明一個(gè)鏈接到單個(gè)實(shí)現(xiàn)類的接口，并且該類的結(jié)構(gòu)類似于以下內(nèi)容

.

├──道

│├──UserDao.java

│└──UserDaoImpl.java

└──服務(wù)

├──UserService.java

└──UserServiceImpl.java

使用Java時(shí)，用于接口編程的接口等同于Java的接口. 實(shí)際上，此接口不是另一個(gè)接口. 有三個(gè)原因

此UserDao界面實(shí)際上并未與外界交互. 它可能是與外界交互的RESTful API，并且此RESTful API是接口編程的接口. 通常，接口或抽象類表示存在多個(gè)實(shí)現(xiàn)，而實(shí)現(xiàn)類以UserDaoImpl編寫(xiě)的命名方法基本上承認(rèn)它是唯一的實(shí)現(xiàn). 從語(yǔ)義上講，UserDao和UserDaoImpl之間沒(méi)有區(qū)別. 將UserDao編寫(xiě)為IUserDao或UserDaoIf是否更難看？如果說(shuō)UserDao下的兩個(gè)實(shí)現(xiàn)是DbUserDao和FileUserDao，則據(jù)說(shuō)過(guò)去UserDao和UserService并未與外界交互，因此它們的定義不穩(wěn)定. 例如，在UserDao中預(yù)定義了一種方法

列表<用戶> findUsersByFirstName（字符串名字）;

它也在UserDaoImpl中實(shí)現(xiàn). 后來(lái)發(fā)現(xiàn)實(shí)現(xiàn)中還需要其他方法

列表<用戶> findUsersByLastName（字符串姓氏）;

因此，我在UserDao界面中添加了此新方法，后來(lái)又實(shí)現(xiàn)了更多方法，然后繼續(xù)將方法添加到UserDao界面中. 在這種情況下，即使將UserDao視為一個(gè)接口，我們所做的也不是先定義該接口，然后再實(shí)現(xiàn)細(xì)節(jié). 但要讓接口根據(jù)實(shí)現(xiàn)需要任意發(fā)展. 隨著時(shí)間的推移，將不可避免地導(dǎo)致UserDao中的方法定義不足. 清晰而混亂，不會(huì)是它的界面.

因此，由于UserDao不是外部接口，并且只有一個(gè)實(shí)現(xiàn)，所以為什么不創(chuàng)建一個(gè)具體的類UserDao. 對(duì)于UserDao的實(shí)現(xiàn)，請(qǐng)編寫(xiě)足夠的測(cè)試用例. 如果UserDao和UserService都只有一個(gè)實(shí)現(xiàn)，則可以將它們放在同一包中，而無(wú)需區(qū)分dao和Service包. 類名暗示了他們的行為.

當(dāng)將來(lái)UserDao需要不同的實(shí)現(xiàn)時(shí)，例如，原始UserDao基于針對(duì)接口編程，可以將其更改為DbUserDao，然后創(chuàng)建FileUserDao. 然后該考慮抽象兩個(gè)公共接口或基類UserDao了. 請(qǐng)記住，通過(guò)足夠的測(cè)試，您可以使用這種重構(gòu)操作來(lái)完成任何您想做的事情. 同時(shí)，隨著類關(guān)系變得越來(lái)越復(fù)雜，Dao和Service類也被適當(dāng)?shù)亟M織為dao和service包.

Spring為什么喜歡UserDao + UserDaoImpl的形式，這是Spring提倡的接口編程針對(duì)接口編程，所以即使只有一個(gè)實(shí)現(xiàn)類，標(biāo)語(yǔ)中的接口也將更改為Java接口接口成為固定模式. 這也使該方法難以在IDE中導(dǎo)航. 直接單擊該方法將轉(zhuǎn)到接口方法，并且您需要按其他鍵. Spring可以使用動(dòng)態(tài)代理來(lái)實(shí)現(xiàn)Java接口方面的原因可能還有另一個(gè)原因，而效率會(huì)更高. 如果直接是類，則必須使用CGLib修改字節(jié)碼以實(shí)現(xiàn)方面. 實(shí)際上，無(wú)論如何，這是一次啟動(dòng)的行為.

Java中軟件包的命名標(biāo)準(zhǔn)建議顛倒域名，后跟與項(xiàng)目相關(guān)的級(jí)別. 例如，如果在Peoplesoft的數(shù)據(jù)服務(wù)部門(mén)下有一個(gè)erp項(xiàng)目，則該項(xiàng)目中dao實(shí)現(xiàn)類的程序包名稱應(yīng)為

com.peoplesoft.dataservice.erp.dao

這可能是一個(gè)很小的項(xiàng)目，只有幾個(gè)類別，每個(gè)類別都掛在這個(gè)長(zhǎng)包裝名稱下. 不僅IDE或VCS中的導(dǎo)航很奇怪，而且感覺(jué)很沉重. 因此，程序包名稱越向前，就越多余. 例如，如下所示，包前綴通常是負(fù)擔(dān).

─com.peopsoft.dataservice.erp

├──主要

├──UserDao

└──UserService

Java包命名標(biāo)準(zhǔn)考慮到該類可能在Internet上傳播，因此，通過(guò)域名部分，您可以基本上確保類的完全限定名稱是唯一的. 但是，絕大多數(shù)是什么？您的班級(jí)僅在此項(xiàng)目中使用，該部門(mén)中的其他項(xiàng)目或公司的其他部門(mén)都可以使用. 通過(guò)引用PlayFramework創(chuàng)建的項(xiàng)目包的名稱很簡(jiǎn)單，即app {controllers，models，service}很簡(jiǎn)單，只有一個(gè)級(jí)別的包名稱. 因此，我們還應(yīng)該在可能被引用的類的范圍內(nèi)定義以下程序包名稱

dao只適合這個(gè)項(xiàng)目

erp.dao可能會(huì)在該部門(mén)的其他項(xiàng)目中使用

dataservice.erp可能會(huì)被我們公司的其他部門(mén)使用

類似于從私人到公共的可見(jiàn)性，并且可以隨時(shí)重建. 它并不僅是搬家，還可以說(shuō)是世界上最偉大的建筑.

“此代碼首先保留（先注釋掉），以后可以使用. ”這不再是保留無(wú)用代碼的原因，否則就不再使用版本控制系統(tǒng). 這類似于旨在支持所有類型的過(guò)度設(shè)計(jì)，一般系統(tǒng)可以更改任何. 該代碼應(yīng)該看起來(lái)干凈. 如果不需要，則必須立即將其刪除. 如果將來(lái)真的有用，請(qǐng)向VCS索取. 這很重要. 預(yù)先標(biāo)記它，然后再搜索.

有機(jī)會(huì)在編程中刪除很多以前寫(xiě)的東西，實(shí)際上是一件很高興的事情. 一般而言，這意味著我們已經(jīng)找到了一種更簡(jiǎn)單的解決方案來(lái)完成這些艱巨的任務(wù).

IntelliJ IDEA可以幫助我們識(shí)別從未調(diào)用的未使用變量或方法. 對(duì)于此灰色區(qū)域（Int??elliJ IDEA查找未使用的變量或以灰色顯示的方法）可以被殺死. 尤其是數(shù)據(jù)類是最嚴(yán)重的. 遵循JavaBean的原始規(guī)范，在聲明字段之后立即生成getter / setter方法，并且可能有很多getter / setter方法，甚至某些屬性本身根本不感興趣. 有必要嗎？ JavaBean是制作樣板代碼的不好的地方，并且JavaBean規(guī)范不再適用于函數(shù)式編程的不變性要求.

IntelliJ IDEA最令人討厭的默認(rèn)模板配置之一是它將自動(dòng)向創(chuàng)建的文件中添加標(biāo)題注釋

/ **

*由Xxx在17年6月6日創(chuàng)建.

* /

IntelliJ IDEA是一種擅長(zhǎng)重構(gòu)的IDEA，但要注意敏捷IDEA，但這是默認(rèn)設(shè)置. 每次看到這樣的文件頭注釋，我都會(huì)感到有些哭泣和大笑. 這不是VCS管理的問(wèn)題嗎？創(chuàng)建者是否在寫(xiě)聲明對(duì)代碼負(fù)責(zé)或警告他人不要打擾我的代碼？實(shí)際上，該代碼歸團(tuán)隊(duì)所有. 直接刪除此標(biāo)題注釋似乎很不禮貌. 無(wú)論如何，通用代碼已更改，最終它可能與創(chuàng)建者無(wú)關(guān). 無(wú)論如何，每次我安裝新的IDEA時(shí)，都首先刪除了文件頭模板.

來(lái)自Yanbin Blog的本文鏈接

本文來(lái)自本站，轉(zhuǎn)載請(qǐng)注明本文網(wǎng)址：
http://www.pc-fly.com/a/jisuanjixue/article-255129-1.html