分层设计思想

通常在设计项目时候总是会采用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 包名.参考类名 （列出父类，引入类，每个类占一行），如果有
* 可省略 
* 相关数据如：（便于理解本类的一些常量数据及某些数据的格式 
* 或认为比较重要的数据，如果没有可省略） 
*/ 
类的声明语法

例如：

/**
* <p>Title:管理员模块数据处理类 </p>
* <p>Description: 两个数相加</p>
* <p>Copyright: Copyright (c) 2007</p>
* <p>Company:华腾软件公司</p>
* 
* @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工具的特征，项目的目录结构为：

src
—-存放java文件 
WebRoot
|–images –存放web程序所需的公共图片
|–css –存放web程序所需的公共样式表
|–js –存放web程序所需的公共js文件
|–commons –存放web程序所需的公共文件
|–功能模块文件夹(存放与某个功能模块相关的资源)
|–images –存放与该功能模块相关的图片
|–css –存放与该模块相关的样式表文件
|–js –存放与该模块相关的js文件
|–jsp、html页面
|–WEB-INF
|–classes
|–lib
|–tld文件

J2EE项目提交规范
项目完成时要将项目作为一个产品交付用户，良好的项目组织规范可以使用户可以方便的找寻项目中需要的资源，同时也是一个公司专业性的体现。项目提交时，要按照下列文件格式进行提交。

项目主文件夹：
作用：存放项目其他资源文件。
命名规范：时间_班级编号_第X小组。
例如：070706_GS2T18_第四小组。

项目主文件夹下面包括以下文件夹和文件：
|–src：保存.java文件。
|–database：保存数据库的脚本文件或者数据库备份文件。
|–source：保存eclipse工程中WebRoot目录下的所有文件。
|–depend：保存编译该程序必须依赖的其他jar文件。
|–javadoc：保存所有类生成的javadoc api文档。
|–war：保存程序的归档文件
|–xx.war：已经打包好的工程文件，可以直接运行。
|–project：保存开发项目原工程代码及文件。
|–产品说明书.doc：图文方式展现该产品使用方法。
|–build.xml：ant脚本，用于生成运行的war文件。
|–项目解说.ppt：进行项目讲解的ppt（ppt仅供在校模拟项目使用，不用于其他商业用途）

注：一个完整的项目中，数据库必须有一定量的有效的测试数据来支持该程序的运行

包的命名　

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