當前位置：首頁 > 编程资源 > 综合教程 >内容正文

综合教程

java J2EE 分层设计思想及各个文件命名规范

發布時間：2023/12/1 综合教程 25 生活家

生活随笔收集整理的這篇文章主要介紹了 java J2EE 分层设计思想及各个文件命名规范小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

分層設計思想

通常在設計項目時候總是會采用MVC設計模式來實現的，這樣子思路清晰，方便以后項目的維護和擴展。

最常見的分層結構如下:

表現層:主要給客戶端顯示的

服務層:為客戶提供服務和功能

領域層:即領域模型，一些javabean之類的對象

DAO層:數據訪問層

設計指導原則:

1.上層總是依賴下層，不要跨層訪問

2.一切從服務層出發，從系統需要提供的功能進行分析，確定service接口中的方法

3.系統最核心的設計就是講兄臺那個的實體劃分為領域模型，在此基礎上設計DAO層

4.每個接口的職責范圍明確有界

DAO:?xxxDAO,?xxxDAOImpl

Service：xxxService,?xxxServiceImpl

Action：

訪問順序應該是這樣的:

View---->Action--->Service--->DAO--->DB

舉個例子(MVC):

顧客去飯店吃飯，面對的肯定是服務員顧客對服務員說我要吃什么什么。服務得知顧客的請求之后，就給廚師說你給我做這些菜給我，廚師(巧婦難為無米之炊)對采購員說你去超市給我買這些原料過來，采購員就屁顛屁帶你的到超市這個大倉庫拿原料過來了。

如果不是使用分層思想設計的話:

如果是小餐館的話可能就會出現這種情況，顧客上來直接問服務員(這個服務員也就是老板娘也是廚師，她啥都干)我要什么什么菜，服務員就去廚房自己買菜自己做菜，然后再自己端菜服務顧客。

三層架構已經學了一段時間,一直想做一個比較完整、比較完美的總結。但是左思右想，不知道如何下筆。都說萬事開頭難嘛，今天整理了一下凌亂的思路，哎，還是沒整理好，想到哪就說到哪吧。

三層架構

初學者很不理解：

1，什么是三層？

2，為什么使用三層？

3，三層與以往使用的兩層相比有什么不同？它的優勢在哪里？

4，如何學好三層？如何應用三層？

……

這篇博客里我會給大家一一解釋一下，略懂皮毛忘大家見諒！！！

米老師一直強調：讓學習和生活結合，把學習和生活聯系，這樣的學習才叫會學習，會生活。

對于三層我左思右想，如何與實際相聯系。好嘛，昨晚突然有了“靈感”。還記得大話設計模式里第23章大鳥和小菜吃羊肉串的故事——由在小攤吃到飯店吃引來的一個命令模式（當然今天不是研究命令模式）。服務員、廚師、采購員。

這不就是個典型的三層架構嗎？？？(⊙?o?⊙?)啊！哈哈（這個后面再做解釋）

先了解：

1,什么是三層？

UI(表現層):主要是指與用戶交互的界面。用于接收用戶輸入的數據和顯示處理后用戶需要的數據。

BLL:(業務邏輯層):UI層和DAL層之間的橋梁。實現業務邏輯。業務邏輯具體包含：驗證、計算、業務規則等等。

DAL:(數據訪問層):與數據庫打交道。主要實現對數據的增、刪、改、查。將存儲在數據庫中的數據提交給業務層，同時將業務層處理的數據保存到數據庫。（當然這些操作都是基于UI層的。用戶的需求反映給界面（UI），UI反映給BLL，BLL反映給DAL，DAL進行數據的操作，操作后再一一返回，直到將用戶所需數據反饋給用戶）

每一層都各負其責，那么該如何將三層聯系起來呢？

1>單項引用（見下圖）

2>這時候實體層（Entity）來了。（注：當然，實體層的作用不止這些）

Entity(實體層)：它不屬于三層中的任何一層，但是它是必不可少的一層。

Entity在三層架構中的作用：

1,實現面向對象思想中的"封裝";

2，貫穿于三層，在三層之間傳遞數據;

（注：確切的說實體層貫穿于三層之間，來連接三層）

3，對于初學者來說，可以這樣理解：每張數據表對應一個實體，即每個數據表中的字段對應實體中的屬性（注：當然，事實上不是這樣。為什么？1＞，可能我們需要的實體在數據表對應的實體中并不存在；2＞，我們完全可以將所有數據表中的所有字段都放在一個實體里）

4，每一層（UI—>BLL—>DAL）之間的數據傳遞（單向）是靠變量或實體作為參數來傳遞的，這樣就構造了三層之間的聯系，完成了功能的實現。

但是對于大量的數據來說，用變量做參數有些復雜，因為參數量太多，容易搞混。比如：我要把員工信息傳遞到下層，信息包括：員工號、姓名、年齡、性別、工資．．．．用變量做參數的話，那么我們的方法中的參數就會很多，極有可能在使用時，將參數匹配搞混。這時候，如果用實體做參數，就會很方便，不用考慮參數匹配的問題，用到實體中哪個屬性拿來直接用就可以，很方便。這樣做也提高了效率。

（注：這里為什么說可以暫時理解為每個數據表對應一個實體？？答：大家都知道，我們做系統的目的，是為用戶提供服務，用戶可不關心你的系統后臺是怎么工作的，用戶只關心軟件是不是好用，界面是不是符合自己心意。用戶在界面上輕松的增、刪、改、查，那么數據庫中也要有相應的增、刪、改、查，而增刪改查具體操作對象就是數據庫中的數據，說白了就是表中的字段。所以，將每個數據表作為一個實體類，實體類封裝的屬性對應到表中的字段，這樣的話，實體在貫穿于三層之間時，就可以實現增刪改查數據了）

綜上所述:三層及實體層之間的依賴關系:

思想來源于生活：

服務員：只管接待客人；

廚師：只管做客人點的菜；

采購員：只管按客人點菜的要求采購食材；

他們各負其職，服務員不用了解廚師如何做菜，不用了解采購員如何采購食材；廚師不用知道服務員接待了哪位客人，不用知道采購員如何采購食材；同樣，采購員不用知道服務員接待了哪位客人，不用知道廚師如何做菜。

他們三者是如何聯系的？

比如：廚師會做：炒茄子、炒雞蛋、炒面——此時構建三個方法（?cookEggplant()、cookEgg()、cookNoodle())

顧客直接和服務員打交道，顧客和服務員（UI層）說：我要一個炒茄子，而服務員不負責炒茄子，她就把請求往上遞交，傳遞給廚師（BLL層），廚師需要茄子，就把請求往上遞交，傳遞給采購員（DAL層），采購員從倉庫里取來茄子傳回給廚師，廚師響應cookEggplant()方法，做好炒茄子后，又傳回給服務員，服務員把茄子呈現給顧客。

這樣就完成了一個完整的操作。

在此過程中，茄子作為參數在三層中傳遞，如果顧客點炒雞蛋，則雞蛋作為參數（這是變量做參數）。如果，用戶增加需求，我們還得在方法中添加參數，一個方法添加一個，一個方法設計到三層；何況實際中并不止設計到一個方法的更改。所以，為了解決這個問題，我們可以把茄子、雞蛋、面條作為屬性定義到顧客實體中，一旦顧客增加了炒雞蛋需求，直接把雞蛋屬性拿出來用即可，不用再去考慮去每層的方法中添加參數了，更不用考慮參數的匹配問題。

這樣講，不知道大家是不是可以明白。（待會實例解釋吧）

2，為什么使用三層？

使用三層架構的目的：解耦！！！

同樣拿上面飯店的例子來講：

（1）服務員（UI層）請假——另找服務員；廚師（BLL層）辭職——招聘另一個廚師；采購員（DAL）辭職——招聘另一個采購員；

（2）顧客反映：1>你們店服務態度不好——服務員的問題。開除服務員；

2>你們店菜里有蟲子——廚師的問題。換廚師；

任何一層發生變化都不會影響到另外一層！！！

3，與兩層的區別？？

兩層：

（當任何一個地方發生變化時，都需要重新開發整個系統。“多層”放在一層，分工不明確耦合度高——難以適應需求變化，可維護性低、可擴展性低）

三層：

（發生在哪一層的變化，只需更改該層，不需要更改整個系統。層次清晰，分工明確，每層之間耦合度低——提高了效率，適應需求變化，可維護性高，可擴展性高）

綜上：三層架構的

優勢：1，結構清晰、耦合度低,2，可維護性高，可擴展性高；3，利于開發任務同步進行；容易適應需求變化

劣勢：1、降低了系統的性能。這是不言而喻的。如果不采用分層式結構，很多業務可以直接造訪數據庫，以此獲取相應的數據，如今卻必須通過中間層來完成。

2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設計符合分層式結構，可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼

3、增加了代碼量，增加了工作量

4,三層的具體表現形式？？

UI：

（大家不要誤會，UI層不只是一個個用戶界面，也是需要有代碼的）

(1,功能：用戶輸入數據、反饋給用戶數據；2,大家觀察代碼:沒有涉及到業務邏輯，直接傳參、函數、方法調用，沒有涉及到與數據庫打交道的SQL語句和ADO.net)

BLL：

（1，BLL是表示層與數據訪問層之間的橋梁，負責數據處理、傳遞；2，大家觀察代碼，沒有涉及到界面上的控件，沒有涉及到SQL語句和ADO.net）

DAL：

(1,以上是DAL層中DbUtil類、user_DA類和workRecord_DA類中的代碼;2,大家觀察代碼，沒有涉及到界面控件，沒有涉及到業務邏輯；只有與數據庫打交道的SQL語句和ADO.net)

Entity（Model）層：

（定義了實體類user）

觀察以上三層：

1，實體類user作為參數貫穿于三層之間；

2，通過傳參、方法調用來實現功能；

3，各層之間各負其責；互不影響

對比兩層結構，讓大家深刻體會三層的極大好處：

還是以機房收費系統的登陸為例：

（觀察上面的兩層的代碼：將業務邏輯、數據訪問都展現在用戶表現層，當需求需要改變時，需要改變整個系統。比如，我把文本框txtPassWord的名稱改為txtPwd的話，大家觀察一下得需要更改多少地方。這樣的改動算是小的，如果真的有業務需求上的改動才叫麻煩復雜，程序員不跳樓才怪。呵呵、、開個玩笑）

與如此難以適應需求變化的兩層相比，大家再次觀察三層代碼，再次思考，三層架構有什么好處呢？自己思考。。。。。

自己去發掘吧！！！

總結：

首先，JavaEE開發分為表示層、業務層、持久化層。而表示層和持久化層需要做的功能比較單一。

1、表示層(action、controller)需要做的就是接受用戶請求、調用業務進行處理、返回需要響應的頁面或者結果，當前，如果有參數，就攜帶著。

2、持久化層(dao、repository)需要做的就是對數據庫的操作，不同框架有不同的處理。但是總而言之，無非就是增刪改查操作，當然，有時候需要很復雜的sql查詢。

3、業務邏輯層(service)，這個就是不同公司的主要業務核心，不同的公司有不同的業務。

　　因此，表示層和持久化層用不同的框架進行開發，而業務層就需要開發人員根據公司的情況進行業務開發。

然后，命名規則就是看公司的具體要求，當然，一些開發過程中也有一些約定成熟的規定，比如包名小寫，并且公司域名反寫等等。

代碼編寫規范目的：能夠在編碼過程中實現規范化，為以后的程序開發中養成良好的行為習慣。
代碼編寫規范使用范圍：J2EE項目開發。

包命名規范：
目的：包的命名規范應當體現出項目資源良好的劃分

servlet類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.servlet
例如：net.linkcn.web.servlet

自定義標簽類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.tags
例如：net.linkcn.web.tags

過濾器類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.filter
例如：net.linkcn.web.filter

Action類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.action
例如：net.linkcn.web.struts.action

ActionForm類所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.form
例如：net.linkcn.web.struts.form

Javabean所在包命名規范：公司名稱.開發組名稱.項目名稱.web.struts.service.impl
例如：net.linkcn.web.service.impl

Javabean實現接口命名規范：公司名稱.開發組名稱.項目名稱.web.service
例如：net.linkcn.web.service

DAO類所在包命名規范：公司名稱.開發組名稱.項目名稱.dao.impl
例如：net.linkcn.dao.impl

DAO類所實現的接口在包中命名規范：公司名稱.開發組名稱.項目名稱.dao
例如：net.linkcn.dao

POJO類與hbm文件所在包命名規范：公司名稱.開發組名稱.項目名稱.dao.hbm
例如：net.linkcn.dao.hbm

全局公共類、接口類所在包命名規范：公司名稱.開發組名稱.項目名稱.global
例如：net.linkcn.global

全局工具類所在包命名規范：公司名稱.開發組名稱.項目名稱.util
例如：net.linkcn.util

類命名規范
基本命名規范：

類、接口命名
命名規范：以大寫字母開頭，如果有多個單詞，每個單詞頭字母大寫
例如：StudentInfo

接口命名
命名規范：以大寫字母"I"開頭，如果有多個單詞，每個單詞頭字母大寫
例如：IStudentInfo

接口實現類命名：
命名規范：將實現的接口名稱的首字母"I"去掉，以"Impl作為結尾"，如果有多個單詞，每個單詞頭字母大寫。
例如：StudentInfoImpl

J2EE+SSH框架命名規范

servlet類命名：
命名規范：以Servlet單詞結尾
例如：LoginServlet

POJO命名：
使用hibernate自動生成的類即可

DAO類命名：
使用hibernate自動生成的類即可

Action類命名：
命名規范：Action的命名以POJO名稱來制定，POJO名稱Action
例如：
一個POJO名稱為Diary，其對應的action為DiaryAction

ActionForm類命名：
命名規范：ActionForm的命名以POJO名稱來制定，POJO名稱Form
例如：
一個POJO名稱為Diary，其對應的actioForm為DiaryForm

業務邏輯接口命名:
命名規范：業務邏輯接口的命名以POJO名稱來制定，IPOJO名稱Service
例如：
一個POJO名稱為Diary，其對應的業務邏輯接口為IDiaryService

業務邏輯實現類命名:
命名規范：業務邏輯接口實現類的命名以POJO名稱來制定
例如：
一個POJO名稱為Diary，對應的業務邏輯接口實現類名為DiaryServiceImpl

類變量命名：
命名規范：變量名首字母必須小寫，如果該變量名有多個單詞組成，后面的單詞首字母大寫，單詞與單詞之間不要使用"_"做連接，變量名訪問控制必須為私有，可以對其增加setter與getter方法。
例如：

private int studentAge;
public int getStudentAge(){
return studentAge;
}
public void setStudentAge(int studentAge) {
this.studentAge=studentAge;
}

常量命名：
命名規范：所有字母大寫，如果有多個單詞組成，單詞與單詞之間以” _“隔開。而且該變量必須是公共、靜態、final類型
例如：public static final String USER_NAME=”userName“;

方法命名
命名規范：首字母必須小寫，如果該變量名有多個單詞組成，后面的單詞首字母大寫，單詞與單詞之間不要使用"_"做連接。單詞不要使用名詞。
例如：public int checkLogin（String name,String pwd）{}

注釋規范：注釋規范是整個開發規范中最為重要的組成部分，必須嚴格執行。
類的注釋：
作用：注釋整個類，簡單概述該類作用。
書寫規范：類的注釋必須寫在該類的聲明語法之前。在注釋中要描述該類的基本作用，作者，日期，版本，公司名稱，版權聲明。
格式：

/* *?
* 類功能描述：（大致描述類的功能）?
* @author：編寫者名稱
*?
* @version：類文件的版本號從1.0開始（自己確定版本號的增改?
* 情況），修改情況（修改時間、作者、改動情況）
*
* @see 包名.參考類名（列出父類，引入類，每個類占一行），如果有
* 可省略?
* 相關數據如：（便于理解本類的一些常量數據及某些數據的格式?
* 或認為比較重要的數據，如果沒有可省略）?
*/?
類的聲明語法

例如：

/**
* Title:管理員模塊數據處理類 
* Description: 兩個數相加
* Copyright: Copyright (c) 2007
* Company:華騰軟件公司
*?
* @author 童金虎
*?
* @version $Revision: 1.7 $ $Date: 2007/07/08$?
*/
public class AdminDAO

變量、常量注釋：
作用：簡單描述該變量的意義。
書寫規范：變量注釋必須寫在變量定義之前，簡單描述其代表的意義。
格式：

/**?
* 變量功能描述：（大致描述變量的功能）
*/

例如：

/**
*定義年齡變量
*/
public int age;

方法注釋：
作用：對該方法功能簡單描述，其參數、返回值意義的注解。
書寫規范：方法注釋必須寫在方法定義之前。該注釋包括：方法其功能的簡單描述，方法的參數、返回值類型、返回值意義簡單的描述。
格式：

/**?
* 方法功能說明?
* @param args (參數類型可以寫在參數后，也可以省?
* 略。每個參數占一行)?
* @return 輸出參數（多種情況寫在同一行）?
* @see 類#參考方法（與此方法有調用關系的方法供參?
* 考，不必每個方法都完整列出，要選擇有意義的，每個?
* 方法占一行）?
* @exception 異常處理類（方法中能夠引發的異常，每?
* 個異常占一行）?
*/

例如：

/**
* 修改管理員密碼
* @param adminId 管理員編號
* @param oldPassword 舊密碼
* @param password 新密碼
* @return boolean 是否編輯成功
* @throws UserException
* @throws ServiceException
*/
public booleaneditAdminPassword(int adminId,String oldPassword,
String password) throws UserException,ServiceException;

Jsp頁面命名：
命名規范：jsp頁面名稱要以小寫字母開頭，如果有多個單詞組成，后面的單詞以大寫字母開頭。名稱要體現出該頁面的意義，最好能夠與模塊名稱聯系在一起。
例如：
login.jsp --登錄頁面
register.jsp --注冊頁面
message.jsp --客戶留言頁面

J2EE項目工程文件夾組織規范：
目的：規范學員web應用程序的資源組織形式，形成良好的文件組織習慣。文件的組織形式應當體現模塊的劃分。
根據eclipse工具的特征，項目的目錄結構為：

J2EE項目提交規范
項目完成時要將項目作為一個產品交付用戶，良好的項目組織規范可以使用戶可以方便的找尋項目中需要的資源，同時也是一個公司專業性的體現。項目提交時，要按照下列文件格式進行提交。

項目主文件夾：
作用：存放項目其他資源文件。
命名規范：時間_班級編號_第X小組。
例如：070706_GS2T18_第四小組。

注：一個完整的項目中，數據庫必須有一定量的有效的測試數據來支持該程序的運行

包的命名　

Java包的名字都是由小寫單詞組成。但是由于Java面向對象編程的特性，每一名Java程序員都可以編寫屬于自己的Java包，為了保障每個 Java包命名的唯一性，在最新的Java編程規范中，要求程序員在自己定義的包的名稱之前加上唯一的前綴。由于互聯網上的域名稱是不會重復的，所以程序員一般采用自己在互聯網上的域名稱作為自己程序包的唯一前綴。?
例如： net.frontfree.javagroup

類的命名

類的名字必須由大寫字母開頭而單詞中的其他字母均為小寫；如果類名稱由多個單詞組成，則每個單詞的首字母均應為大寫例如TestPage；如果類名稱中包含單詞縮寫，則這個所寫詞的每個字母均應大寫，如：XMLExample,還有一點命名技巧就是由于類是設計用來代表對象的，所以在命名類時應盡量選擇名詞。　　?
例如： Circle

方法的命名

方法的名字的第一個單詞應以小寫字母作為開頭，后面的單詞則用大寫字母開頭。?
例如： sendMessge

常量的命名

常量的名字應該都使用大寫字母，并且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下劃線來分割這些單詞。?
例如： MAX_VALUE

參數的命名

參數的命名規范和方法的命名規范相同，而且為了避免閱讀程序時造成迷惑，請在盡量保證參數名稱為一個單詞的情況下使參數的命名盡可能明確。

Javadoc注釋

Java除了可以采用我們常見的注釋方式之外，Java語言規范還定義了一種特殊的注釋，也就是我們所說的Javadoc注釋，它是用來記錄我們代碼中的API的。Javadoc注釋是一種多行注釋，以/**開頭，而以*/結束，注釋可以包含一些HTML標記符和專門的關鍵詞。使用Javadoc 注釋的好處是編寫的注釋可以被自動轉為在線文檔，省去了單獨編寫程序文檔的麻煩。?
例如：

/**?
* This is an example of?
* Javadoc?
*?
* @author darchon?
* @version 0.1, 10/11/2002?
*/

在每個程序的最開始部分，一般都用Javadoc注釋對程序的總體描述以及版權信息，之后在主程序中可以為每個類、接口、方法、字段添加 Javadoc注釋，每個注釋的開頭部分先用一句話概括該類、接口、方法、字段所完成的功能，這句話應單獨占據一行以突出其概括作用，在這句話后面可以跟隨更加詳細的描述段落。在描述性段落之后還可以跟隨一些以Javadoc注釋標簽開頭的特殊段落，例如上面例子中的@auther和@version，這些段落將在生成文檔中以特定方式顯示。

變量和常量命名

變量命名的方法采用匈牙利命名法，基本結構為scope_typeVariableName，它使用3字符前綴來表示數據類型，3個字符的前綴必須小寫，前綴后面是由表意性強的一個單詞或多個單詞組成的名字，而且每個單詞的首寫字母大寫，其它字母小寫，這樣保證了對變量名能夠進行正確的斷句。例如，定義一個整形變量，用來記錄文檔數量：intDocCount，其中int表明數據類型，后面為表意的英文名，每個單詞首字母大寫。這樣，在一個變量名就可以反映出變量類型和變量所存儲的值的意義兩方面內容，這使得代碼語句可讀性強、更加容易理解。byte、int、char、long、float、 double、boolean和short。

變量類型和首字母對照關系如下表：

數據類型/對象類型 / 變量前綴 / 備注

byte bye?
char chr?
float flt?
boolean bln 做布爾變量時，使用bln?
Integer/int int?
String str?
Single sng?
short sht?
Long/long lng?
Double/double dbl?
Currency cur?
Variant bln astr obj vnt 做布爾變量用時，用bln，做字符串數組用時，用astr，做為對象使用時，用obj，不確定時，用vnt。

對于數組，在數據類型的前綴前再增加一個a，例如字符串數組為astr。對于在多個函數內都要使用的全局變量，在前面再增加“g_”。例如一個全局的字符串變量：g_strUserInfo。

在變量命名時要注意以下幾點：

· 選擇有意義的名字，注意每個單詞首字母要大寫。

· 在一段函數中不使用同一個變量表示前后意義不同的兩個數值。

· i、j、k等只作為小型循環的循環索引變量。

· 避免用Flag來命名狀態變量。

· 用Is來命名邏輯變量，如：blnFileIsFound。通過這種給布爾變量肯定形式的命名方式，使得其它開發人員能夠更為清楚的理解布爾變量所代表的意義。

· 如果需要的話，在變量最后附加計算限定詞，如：curSalesSum。

· 命名不相包含，curSales和curSalesSum。

· Static Final 變量的名字應該都大寫，并且指出完整含義。

· 如果需要對變量名進行縮寫時，一定要注意整個代碼中縮寫規則的一致性。例如，如果在代碼的某些區域中使用intCnt，而在另一些區域中又使用intCount，就會給代碼增加不必要的復雜性。建議變量名中盡量不要出現縮寫。

· 通過在結尾處放置一個量詞，就可創建更加統一的變量，它們更容易理解，也更容易搜索。例如，請使用 strCustomerFirst和strCustomerLast，而不要使用strFirstCustomer和strLastCustomer。常用的量詞后綴有：First（一組變量中的第一個）、Last（一組變量中的最后一個）、Next（一組變量中的下一個變量）、Prev（一組變量中的上一個）、Cur（一組變量中的當前變量）。

· 為每個變量選擇最佳的數據類型，這樣即能減少對內存的需求量，加快代碼的執行速度，又會降低出錯的可能性。用于變量的數據類型可能會影響該變量進行計算所產生的結果。在這種情況下，編譯器不會產生運行期錯誤，它只是迫使該值符合數據類型的要求。這類問題極難查找。

· 盡量縮小變量的作用域。如果變量的作用域大于它應有的范圍，變量可繼續存在，并且在不再需要該變量后的很長時間內仍然占用資源。它們的主要問題是，任何類中的任何方法都能對它們進行修改，并且很難跟蹤究竟是何處進行修改的。占用資源是作用域涉及的一個重要問題。對變量來說，盡量縮小作用域將會對應用程序的可靠性產生巨大的影響。

關于常量的命名方法，在JAVA代碼中，無論什么時候，均提倡應用常量取代數字、固定字符串。也就是說，程序中除0，1以外，盡量不應該出現其他數字。常量可以集中在程序開始部分定義或者更寬的作用域內，名字應該都使用大寫字母，并且指出該常量完整含義。如果一個常量名稱由多個單詞組成，則應該用下劃線“_”來分割這些單詞如：NUM_DAYS_IN_WEEK、MAX_VALUE。

資料來源于網絡

參考：

http://blog.csdn.net/faithpassion/article/details/38494443

http://blog.csdn.net/mr_li13/article/details/50286145

轉載于:https://www.cnblogs.com/binglong180/p/7849802.html

總結

以上是生活随笔為你收集整理的java J2EE 分层设计思想及各个文件命名规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：香港服务器使用CDN加速对网站有什么好处
下一篇： root大师一直卡在99怎么回事