java包裝項目

程序包是Java的基本概念，是您開始用該語言編程時偶然發(fā)現(xiàn)的第一件事。 作為一個初學(xué)者，您可能不太關(guān)注軟件包的結(jié)構(gòu)，但是隨著您成為經(jīng)驗豐富且成熟的軟件開發(fā)人員，您開始考慮可以采取哪些措施來提高其效率。 有幾個主要選項需要考慮，選擇正確的選項可能不是一個顯而易見的選擇。 本文應(yīng)該為您提供常用策略的概述。

我們?yōu)槭裁词褂冒?#xff1f;

從語言的角度來看，Java包提供了兩個重要的功能，編譯器可以利用它們。 最明顯的一個是類的名稱空間定義。 幾個名稱完全相同的類可以在一個項目中使用，只要它們屬于不同的包即可將一個類與另一個類區(qū)分開。 如果您無法想象如果沒有包，該語言將是什么樣子，那么請看一下JavaScript世界中的模塊化策略。 在ES2015之前，沒有官方標(biāo)準(zhǔn)，而且命名沖突并非罕見。

第二件事是，程序包允許為項目的特定成員定義訪問修飾符。 對于不同包的成員，可以限制或完全禁止類，接口或其成員（如字段和方法）的可訪問性。

編譯器首先使用這兩個功能來實施語言規(guī)則。 對于干凈的編碼人員和軟件技術(shù)人員而言，軟件包的主要屬性可能具有有意義的名稱，該名稱描述了軟件包的用途和存在的原因。 對于編譯器，這只是一個隨機的char字符串，而對于我們來說，這是表達(dá)我們意圖的另一種方式。

什么是包裹？

在官方的Java教程中，我們可以找到以如下形式開頭的定義：

程序包是一個命名空間，用于組織一組相關(guān)的類和接口。 從概念上講，您可以將軟件包視為類似于計算機上的不同文件夾。 您可以將HTML頁面保留在一個文件夾中，將圖像保留在另一個文件夾中，并將腳本或應(yīng)用程序保留在另一個文件夾中。 （...）

第一句話強調(diào)軟件包的組織目的。 但是，該定義并未說明應(yīng)將哪種關(guān)系類和接口視為一個單獨的組。 這個問題向所有軟件開發(fā)人員開放。 最近，肯特·貝克（Kent Beck）寫了一條一般性建議，該建議也適用于本文中討論的主題：

如果您一直想知道該如何清理，請將相似的元素移到更近的位置，并將不同的元素移到更遠(yuǎn)的位置

-肯特·貝克（@KentBeck） 2017年6月26日

但是，就像上述包裝定義中的“相關(guān)”一詞一樣，“相似”一詞對不同的人可能具有完全不同的含義。 在本文的其余部分，我們將在軟件包組織的背景下考慮可能的選擇。

逐層包裝

項目類之間最普遍公認(rèn)的相似之處可能是他們的責(zé)任。 使用此屬性進(jìn)行組織的方法稱為逐層打包或水平切片，實際上，其外觀或多或少類似于下圖。

如果您沒有機會從事具有這種結(jié)構(gòu)的項目，則可以在一些框架教程中找到它。 例如，Play框架建議在2.2版之前使用這種方法。 Angular.js的教程最初建議根據(jù)其職責(zé)將事物保持在一起。

他們改變了對主題的看法，并更新了教程，這可能會讓您思考是什么原因。 但是在判斷解決方案之前，讓我們先看一下它的優(yōu)缺點。

優(yōu)點

考慮到分層體系結(jié)構(gòu)是使用最廣泛的體系結(jié)構(gòu)，開發(fā)人員旨在在包結(jié)構(gòu)中反映所選體系結(jié)構(gòu)也就不足為奇了。 這種方法的長期流行會影響將結(jié)構(gòu)應(yīng)用到新項目中的決定，因為團(tuán)隊的新手更容易在他們熟悉的環(huán)境中采用他們。

在此類應(yīng)用程序中為新類找到合適的位置實際上是理所當(dāng)然的操作。 該結(jié)構(gòu)是在開發(fā)之初創(chuàng)建的，并且在整個項目存在期間都保持不變。 這種簡單性使得即使經(jīng)驗不足的開發(fā)人員也可以使項目保持秩序，因為結(jié)構(gòu)易于理解。

缺點

有人說將所有模型類放在一個位置使它們更易于重用，因為它們可以與整個包一起簡單地復(fù)制到另一個項目中。 但是真的是這樣嗎？ 特定域模型的形狀通常僅在項目內(nèi)的有限上下文中有效。 例如，產(chǎn)品類別在購物應(yīng)用程序中將具有與管理制造商訂單的應(yīng)用程序不同的屬性。 即使您想使用相同的類，也有必要將它們提取到每個應(yīng)用程序中標(biāo)記為依賴項的單獨jar中。 即使存在于獨立但相關(guān)的項目中，代碼重復(fù)也會導(dǎo)致錯誤，因此我們應(yīng)避免粘貼粘貼。

逐層打包方法的主要缺點是過度使用了公共訪問修飾符。 現(xiàn)代的IDE默認(rèn)情況下使用public修飾符創(chuàng)建類和方法，而不會強迫開發(fā)人員考慮使用更合適的選項。 實際上，在分層包組織中沒有其他選擇。 僅將存儲庫公開給單個服務(wù)類，就要求該存儲庫是公共的。 副作用是，項目中的所有其他類都可以訪問該存儲庫，即使是不應(yīng)該與其直接通信的層也可以訪問該存儲庫。 這種方法鼓勵創(chuàng)建無法維護(hù)的意大利面條代碼，并導(dǎo)致包裝之間的高度耦合。

如今，無論它們在何處，都可以在IDE中的已連接類之間輕松切換，但為新功能添加新的類集需要更多的注意。 當(dāng)類分布在多個目錄中時， 僅通過查看代碼也很難評估功能的復(fù)雜性 。

一開始，我們說過程序包的名稱應(yīng)提供有關(guān)其內(nèi)容的其他詳細(xì)信息。 在逐包方法中，所有程序包都描述了解決方案的體系結(jié)構(gòu)，但是它們分別沒有提供任何有用的信息。 實際上，在許多情況下，它們會復(fù)制其成員的類名中顯示的信息。

按功能包裝

在硬幣的另一面，您可以圍繞要素或領(lǐng)域模型構(gòu)建類。 您可能已經(jīng)聽說過這種方法是垂直切片組織。 如果僅使用水平切片，乍一看可能看起來有些混亂，但是最后這只是心態(tài)問題。 下圖表示與上一段相同的類，但包裝布局不同。

您可能不會僅僅因為左腳適合同一只腳而將所有左腳鞋放在一個位置，而另一只腳就放在另一位置。 您要成對穿著鞋子，因為那是您使用鞋子的方式。 同樣，您可以查看項目中的類。

垂直切片的核心思想是將構(gòu)建特定功能的所有類放在單個程序包中。 遵循此規(guī)則，您將獲得一些好處，但同時也會面臨一些負(fù)面后果。

優(yōu)點

當(dāng)所有要素類都放在一個程序包中時，public access修飾符更具表現(xiàn)力，因為它允許描述要素的哪一部分應(yīng)由應(yīng)用程序的其他部分訪問。 在包內(nèi)，您應(yīng)該贊成使用package-private修飾符來改善模塊化。 最好在IDE中修改默認(rèn)模板，以避免創(chuàng)建公共類和方法。 公開一些東西應(yīng)該是一個有意識的決定。 來自不同程序包的類之間較少的連接將導(dǎo)致更簡潔，更可維護(hù)的代碼庫。

在水平切片中，程序包在每個項目中具有相同的名稱集，而在垂直切片方法中， 程序包具有更有意義的名稱，這些名稱描述了它們的功能用途 。 僅通過查看項目結(jié)構(gòu)，您就可以猜測用戶可以使用該應(yīng)用程序做什么。 該方法還表達(dá)了要素之間的層次關(guān)系。 域的聚合根很容易識別，因為它們存在于程序包樹的最低層。 包結(jié)構(gòu)記錄了應(yīng)用程序。

根據(jù)功能對類進(jìn)行分組可以使程序包更小，更容易瀏覽。 在橫向方法中，每個新功能都會增加圖層包中類的總數(shù)，并使它們更難瀏覽。 在長長的類列表中找到有趣的元素將成為一種低效率的活動。 相比之下， 僅當(dāng)擴展了功能時 ， 關(guān)注該功能的軟件包才會增長 。 新功能在樹的適當(dāng)節(jié)點中接收其自己的包。

還值得一提的是垂直切片包裝的靈活性。 隨著微服務(wù)架構(gòu)的日益普及，擁有已經(jīng)按功能分割的整體應(yīng)用程序絕對比將項目按層組織的項目更容易轉(zhuǎn)換成單獨的服務(wù)。 采用按功能打包的方法可以為應(yīng)用程序的可擴展性增長做好準(zhǔn)備。

缺點

隨著項目的發(fā)展，軟件包的結(jié)構(gòu)需要更多的注意。 重要的是要了解，隨著應(yīng)用程序變得越來越復(fù)雜，程序包樹會隨著時間而發(fā)展。 您有時會不得不停一會兒，并考慮將程序包移動到其他節(jié)點或?qū)⑵洳鸱譃檩^小的節(jié)點。 結(jié)構(gòu)的清晰度不是免費的。 團(tuán)隊負(fù)責(zé)保持其良好狀態(tài)，并與該領(lǐng)域的知識保持一致。

了解領(lǐng)域是清潔項目結(jié)構(gòu)的關(guān)鍵要素。 為新功能選擇合適的位置可能會遇到問題，特別是對于團(tuán)隊新手來說，因為這需要您應(yīng)用程序背后的業(yè)務(wù)知識。 某些人可能會認(rèn)為這是一種優(yōu)勢，因為這種方法鼓勵團(tuán)隊成員之間共享知識。 向該項目介紹新的開發(fā)人員比較耗時，但可能會被視為一項投資。

混合方式

您可能認(rèn)為四肢沒有好處。 我們難道不能僅從兩種方法中取最大的優(yōu)點，并創(chuàng)造介于兩個極端之間的新質(zhì)量嗎？ 有兩種可能的組合。 程序包的第一層被一層劃分，要素是它們的子級，要素建立在頂層，層是它們的子節(jié)點。

第一種選擇是您可能遇到的，因為它是增長到大尺寸包裝的常見解決方案。 它增加了結(jié)構(gòu)的清晰度，但是不幸的是，逐層封裝方法的所有缺點都像以前一樣適用。 最大的問題是，仍然必須在幾乎所有地方都使用public修飾符，以連接您的類和接口。

使用另一個選項，我們應(yīng)該問一個問題，該解決方案是否真的有意義。 按功能打包的方法支持層的組織，但它是在類級別上而不使用package的 。 通過引入其他級別的軟件包，我們將失去利用默認(rèn)訪問修飾符的能力。 我們在結(jié)構(gòu)上也沒有獲得太多簡化。 如果功能包增長到難以管理的大小，則提取子功能可能更好。

摘要

在開始新項目時，選擇包結(jié)構(gòu)是您必須要做的第一選擇。 該決定會影響整個解決方案的未來可維護(hù)性。 盡管從理論上講，您可以在任何時間點更改方法，但是通常，這種轉(zhuǎn)移的總成本只會阻止這種轉(zhuǎn)移的發(fā)生。 這就是為什么在開始時與整個團(tuán)隊花費幾分鐘并比較可能的選擇尤為重要的原因。 一旦做出選擇，您要做的就是確保每個開發(fā)人員都遵循相同的策略。 對于按功能打包的方法來說，這可能會比較困難，特別是如果是第一次使用，但是好處列表絕對值得努力。

如果您對垂直切面有任何經(jīng)驗，并且想在主題中增加兩分錢， 請隨時在評論中分享您的想法 。 另外，請考慮與您的同事分享該帖子。 閱讀您的討論結(jié)果和對該方法的感受將是很棒的。

翻譯自: https://www.javacodegeeks.com/2017/07/project-package-organization.html

java包裝項目

總結(jié)

以上是生活随笔為你收集整理的java包装项目_项目包装组织的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。