用户33623396
有效的Java编程原则是怎样的？
1避免创建不必要的对象 String s=new String(＂stringette＂); //don't do this 改语句每次执行的时候都会创建一个String的实例，若改语句被频繁的调用，就会出现成千上万的不必要的String实例.改进后的版本： String s=＂stringette＂; 2接口优与抽象类.复合优先继承.. 3不要在新的代码中使用原生态类型.最后使用包装类.，优先考虑泛型. 4优先考虑安全类的容器类. 5用enum代替int常量 6坚持使用override注解. 7不用用String拼接字符串，多用StringBuffer 8在有异常的情况下使用异常，优先使用标准的异常，避免过多的在一个方法里嵌套多个异常.并努力是失败保持原子性，更不要忽略了异常，在 9 for -each 循环优先传统的for循环， 10不要写过长的方法，最后有清楚的注释，遵守普遍接受的命名规则 11注意线程安全的问题，主要是变量共享和线程同步这两个方面 12尽量不要使用线程组.应为它不安全 13注意对象的序列化. 以上是我对于这个问题的解答，希望能够帮到大家。
java软件开发的代码规范
展开全部 1、组织与风格（1）.关键词和操作符之间加适当的空格。
（2）.相对独立的程序块与块之间加空行（3）.较长的语句、表达式等要分成多行书写。
（4）.划分出的新行要进行适应的缩进，使排版整齐，语句可读。
（5）.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
（6）.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
（7）.若函数或过程中的参数较长，则要进行适当的划分。
（8）.不允许把多个短语句写在一行中，即一行只写一条语句。
（9）.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
注：如果大家有兴趣可以到安安DIY创作室博客，有相关说明性的文章和解释。
2、注解Java 的语法与 C++ 及为相似，那么，你知道 Java 的注释有几种吗？是两种？// 注释一行/* ...... */ 注释若干行不完全对，除了以上两种之外，还有第三种，文档注释：/** ...... */ 注释若干行，并写入 javadoc 文档注释要简单明了。
String userName = null； //用户名边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
在必要的地方注释，注释量要适中。
注释的内容要清楚、明了，含义准确，防止注释二义性。
保持注释与其描述的代码相邻，即注释的就近原则。
对代码的注释应放在其上方相邻位置，不可放在下面。
对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；同一结构中不同域的注释要对齐。
变量、常量的注释应放在其上方相邻位置或右方。
全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。
/*** Copy Right Information : Neusoft IIT* Project : eTrain* JDK version used : jdk1.3.1* Comments : config path* Version : 1.01* Modification history :2003.5.1* Sr Date Modified By Why & What is modified* 1. 2003.5.2 Kevin Gao new**/在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等/*** Description :checkout 提款* @param Hashtable cart info* @param OrderBean order info* @return String*/public String checkout(Hashtable htCart,OrderBean orderBean)throws Exception{}javadoc注释标签语法@author 对类的说明 标明开发该类模块的作者@version 对类的说明 标明该类模块的版本@see 对类、属性、方法的说明 参考转向，也就是相关主题@param 对方法的说明 对方法中某参数的说明@return 对方法的说明 对方法返回值的说明@exception 对方法的说明 对方法可能抛出的异常进行说明3、命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。
（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）较短的单词可通过去掉元音形成缩写；要不然最后自己写的代码自己都看不懂了，那可不行。
较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
使用匈牙利表示法Package 的命名Package 的名字应该都是由一个小写单词组成。
package com.neu.utilClass 的命名Class 的名字必须由大写字母开头而其他字母都小写的单词组成，对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
public class ThisAClassName{}Class 变量的命名变量的名字必须用一个小写字母开头。
后面的单词用大写字母开头userName , thisAClassMethodStatic Final 变量的命名static Final 变量的名字应该都大写，并且指出完整含义。
/***DBConfig PATH**/public static final StringDB_CONFIG_FILE_PATH =com.neu.etrain.dbconfig；参数的命名参数的名字必须和变量的命名规范一致。
数组的命名数组应该总是用下面的方式来命名：byte[] buffer；而不是：byte buffer[]；方法的参数使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：SetCounter(int size){this.size = size;}4、文件样式所有的 Java(*.java) 文件都必须遵守如下的样式规则：版权信息版权信息必须在 java 文件的开头，比如：/** Copyright ? 2000 Shanghai XXX Co. Ltd.* All right reserved.*/其他不需要出现在 javadoc 的信息也可以包含在这里。
Package/Importspackage 行要在 import 行之前，import 中标准的包名要在本地的包名之前，而且按照字母顺序排列。
如果 import 行中包含了同一个包中的不同子目录，则应该用 * 来处理。
package hotlava.net.stats;import java io.*;import java.util.Observable;import hotlava.util.Application；这里 java。
io.* 使用来代替InputStream and OutputStream 的。
Class接下来的是类的注释，一般是用来解释类的。
/*** A class representing a set of packet a...
java并发编程设计原则与模式 怎么样
本书全面介绍了如何使用java 2平台进行并发编程，较上一版新增和扩展的内容包括： ·存储模型 ·取消 ·可移植的并行编程 ·实现并发控制的工具类 java平台提供了一套广泛而功能强大的api，工具和技术。
内建支持线程是它的一个强大的功能。
这一功能为使用java编程语言的程序员提供了解并发编程这一诱人但同时也非常具有挑战性的选择。
本书通过帮助读者理解有关并发编程的模式及其利弊，向读者展示了如何更精确地使用java平台的线程模型。
Java注释的原则有哪些呢？
1、 注释形式统一 在整个应用程序中，使用具有一致的标点和结构的样式来构造注释。
如果在其他项目组发现他们的注释规范与这份文档不同，按照他们的规范写代码，不要试图在既成的规范系统中引入新的规范。
2、 注释的简洁 内容要简单、明了、含义准确，防止注释的多义性，错误的注释不但无益反而有害。
3、 注释的一致性 在写代码之前或者边写代码边写注释，因为以后很可能没有时间来这样做。
另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。
通常描述性注释先于代码创建，解释性注释在开发过程中创建，提示性注释在代码完成之后创建。
修改代码的同时修改相应的注释，以保证代码与注释的同步。
4、 注释的位置 保证注释与其描述的代码相邻，即注释的就近原则。
对代码的注释应放在其上方相邻或右方的位置，不可放在下方。
避免在代码行的末尾添加注释；行尾注释使代码更难阅读。
不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释要对齐。
5、 注释的数量 注释必不可少，但也不应过多，在实际的代码规范中，要求注释占程序代码的比例达到20%左右。
注释是对代码的“提示”，而不是文档，程序中的注释不可喧宾夺主，注释太多了会让人眼花缭乱，注释的花样要少。
不要被动的为写注释而写注释。
6、删除无用注释 在代码交付或部署发布之前，必须删掉临时的或无关的注释，以避免在日后的维护工作中产生混乱。
7、 复杂的注释 如果需要用注释来解释复杂的代码，请检查此代码以确定是否应该重写它。
尽一切可能不注释难以理解的代码，而应该重写它。
尽管一般不应该为了使代码更简单便于使用而牺牲性能，但必须保持性能和可维护性之间的平衡。
8、 多余的注释 描述程序功能和程序各组成部分相互关系的高级注释是最有用的，而逐行解释程序如何工作的低级注释则不利于读、写和修改，是不必要的，也是难以维护的。
避免每行代码都使用注释。
如果代码本来就是清楚、一目了然的则不加注释，避免多余的或不适当的注释出现。
9、必加的注释 典型算法必须有注释。
在代码不明晰或不可移植处必须有注释。
在代码修改处加上修改标识的注释。
在循环和逻辑分支组成的代码中添加注释。
为了防止问题反复出现，对错误修复和解决方法的代码使用注释，尤其是在团队环境中。
10、注释在编译代码时会被忽略，不编译到最后的可执行文件中，所以注释不 会增加可执行文件的大小。
网站设计的原则
网站中有哪些关键技巧？有哪些陷阱？在这里，世界上一流的网站设计专家，让你共享他们的秘密，告诉你：使网站赋予情趣的诀窍、应该避免做什么、应使用什么工具软件以及他们喜爱和厌恶的网站。
01 明确内容 如果你想成为一个网站设计者，并正想建一个网站的话，首先应该考虑网站的内容，包括网站功能和你的用户需要什么。
你的整个设计都应该围绕这些方面来进行。
02 抓住用户 如果用户不能够迅速地进入你的网站，或操作不便捷，网站设计就是失败的。
不要让用户失望而转向你的对手的网站。
03 优化内容 内容是核心。
大约在两年以前，企业网站就像一本广告册子，更槽糕的是，网站使用了大量的图片，似乎要几个世纪才能下载完。
Chanels网站（www.channels.co.uk）在设计的某些方面是成功的，但是内容太贪乏，并且要花很长时间才能找到所要的东西，因此不能算是一个成功的网站。
04 快速下载 没有什么比要花很长时间下载页面更槽糕的了。
作为一条经验，一个标准的网页应不大于60K，通过56K调制解调器加载花30秒的时间。
有的设计者说网页加载应在15秒内。
05 网站升级 时刻注意网站的运行状况。
性能很好的主机随着访问人数的增加，可能会运行缓慢。
但是，如果你不想失去访问者的话，一定要仔细计划好你的升级计划。
06 坚持基本原则 即使你不懂HTML语言，你只需购买一个有版权的所见即所得的网页设计工具，如Adobe PageMill 或 Microsoft FrontPage Express，就可以创建一个看起来很合理的网站。
但是，在设计时，这些软件包虽然不需要HTML，却使网站速度下降。
为了成功地设计网站，你必须理解HTML是如何工作的。
大多数的网站设计者建议网络新手应从有关HTML的书中去寻找答案，用Notepad制作网页。
07 学习HTML 用HTML设计网站，可以控制设计的整个过程。
但是，如果你仅仅是网站设计的新手，你应该寻找一个允许修改HTML的软件包。
HomeSite4是一个很好的Web设计工具。
在设计过程中，HomeSite4能帮助你学习HTML。
它还允许你切换到所见即所得的模式，以便你在把网站发送到Web之前，预览你的网站。
08 用笔画一个网站的框架 圣人云：笔比剑更强大。
在用计算机之前，用笔画一个网站的框架，显示出所有网页的相互关系。
计划好你的用户如何以最少的时间浏览你的网站。
09 “在计算机上永远也找不到好的方案”。
——专家忠告 10 网站地图 许多设计者把他们的网站地图放在网站上，这种做法，却是弊大于利。
绝大部分的访问者上网是寻找一些特别的信息，他们对于你的网站是如何工作的，并没有兴趣。
如果你觉得你的网站需要地图，那很可能是需要改进你的导航和工具条。
11 “睁大你的眼睛，留意所有的事情。
” “对最不相关的东西的观察可以得到最好的灵感。
观察一个站点的结构和设计。
理解站点结构的关键元素，确保你的设计是围绕站点浏览进行的。
” ——专家忠告 12 点击规则 听说过3次点击规则吗？对于小型网站，在你的主页上，没有任何一条信息，需要点击次数超过3次的。
对于大型网站，使用导航和工具条来改善操作。
13 特殊字体的应用 虽然你可以在你的HTML中使用特殊的字体，但是，你不可能预测你的访问者在他们的计算机上将看到什么。
在你的计算机里看起来相当好的页面，在另一个不同的平台上看起来可能非常糟糕。
一些网站设计员喜欢使用来定义特性，这虽然允许你使用特殊的字体，但是仍需要一些变通的方法，以免你所选择的字体在访问者的计算机上不能显示。
级联风格表CSS有助于解决这些问题，但是只有最新版的浏览器才支持CSS。
14 “使用切合实际的简便的命名规则。
” ——专家忠告 15 检查错别字 好的拼写是人们一生中重要的技能。
但是遗憾的是，许多设计者都缺少这种技能。
确保你拼写正确，并且格外注意平常容易误写的错别字。
16 避免长文本页面 在一个站点上有许多只有文本的页面，是令人乏味的，且也浪费Web的潜力。
如果你有大量的基于文本的文档，应当以Adobe Acrobat格式的文件形式来放置，以便你的访问者能离线阅读。
17 不要使用卷滚条 人们厌恶在网上使用卷滚条。
Trouble网站（www.Trouble.co.uk）是一个典型的设计很差的网站。
它基于一个浮动的架构，为了阅读所有的文本，浏览者不得不使用卷滚条。
18 专家最喜爱的Web设计工具 1.Adobe Photoshop 2.Macromedia Flash 3.Adobe Illustrator 4.Adobe ImageRead 5.Dreamweaver 6.Macromedia Fireworks 7. Allaire Homesites 8.Microsoft Notepad 9. Macromedia Director 10. Lightwave 11. Macromedia Freehand 12.其它：Adobe Acrobat Exchange,Allaire ColdFusion,BBEdit,HTML Validator等。
19 网站介绍 你应当有一个很清晰的网站介绍，告诉访问者你的网站能够提供些什么，以便访问者能找到想要的东西。
但是，许多设计者都没有这样做。
有效的导航条和搜索工具使人们很容易找到有用的信息，这对访问者很重要。
告诉访问者你所提供的正是他们想要的信息。
20 “网站一旦发布，网站设计的优点和缺陷全都公布于世。
没有什么方法使你能够比从自己的错误、倾听其他人的建议和用...
用户界面设计原则有什么
展开全部 软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。
从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。
其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展，层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。
依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。
这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。
但软件架构毕竟是建立在当前技术之上的。
而每一代技术都有架构模式。
过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。
我们从三层次架构谈起：因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。
cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。
JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。
推荐作为持久层的首选在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。
而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层，虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。
struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务（tool:jaas）、流程控制服务workflow、动态实现服务IOC，串行化消息服务（tool:jms）、负载平衡服务blance等。
如果我们不采用重量级应用服务器（如weblogic,websphere,jboss等）及重量级组件（EJB），我们必须自己实现其中一些服务。
虽然我们大 多情况下，不需要所有这些服务，但实现起来却非易事。
幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要，一些xml文档操作工具（DOM,Digester,SAX等）的使用愈发重要，而随着 xml schema的java binding工具（jaxb,xmlbean等）工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式，而这又进一步使数据中心向xml转移，使在中小数据量上，愈发倾向于以xquery为查询语言的xml数据库。
现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如（microsoft office之infopath），可以直接从xml schema 生成录入页面等非常实用的功能。
还有web service 的广泛应用，都将对软件的架构有非常重大的影响。
至于面向服务架构（SOA）前景如何，三层次架构什么时候走入历史，现还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。
也许作为一个很好的思想，它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样，广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
javaBean设计原则
是指JavaBean的设计规则么？编写JavaBean必须满足以下几点：1、所有的JavaBean必须放在一个包中；2、JavaBean必须声明成public class类型，并且文件名与类名必须相一致；3、所有的属性必须封装；4、设置和取得属性可以通过setter和getter;5、使用JSP标签去调用JavaBean时必须有一个无参构造方法；基本上就这些了，还有一些诸如命名规则的一些东西可以参照Java的。
Java企业软件开发设计说明书如何做
展开全部1、组织与风格（1）.关键词和操作符之间加适当的空格。
（2）.相对独立的程序块与块之间加空行（3）.较长的语句、表达式等要分成多行书写。
（4）.划分出的新行要进行适应的缩进，使排版整齐，语句可读。
（5）.长表达式要在低优先级操作符处划分新行，操作符放在新行之首。
（6）.循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分。
（7）.若函数或过程中的参数较长，则要进行适当的划分。
（8）.不允许把多个短语句写在一行中，即一行只写一条语句。
（9）.函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格。
注：如果大家有兴趣可以到安安DIY创作室博客，有相关说明性的文章和解释。
2、注解Java 的语法与 C++ 及为相似，那么，你知道 Java 的注释有几种吗？是两种？// 注释一行/* ...... */ 注释若干行不完全对，除了以上两种之外，还有第三种，文档注释：/** ...... */ 注释若干行，并写入 javadoc 文档注释要简单明了。
String userName = null； //用户名边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性。
在必要的地方注释，注释量要适中。
注释的内容要清楚、明了，含义准确，防止注释二义性。
保持注释与其描述的代码相邻，即注释的就近原则。
对代码的注释应放在其上方相邻位置，不可放在下面。
对数据结构的注释应放在其上方相邻位置，不可放在下面；对结构中的每个域的注释应放在此域的右方；同一结构中不同域的注释要对齐。
变量、常量的注释应放在其上方相邻位置或右方。
全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明。
在每个源文件的头部要有必要的注释信息，包括：文件名；版本号；作者；生成日期；模块功能描述（如功能、主要算法、内部各部分之间的关系、该文件与其它文件关系等）；主要函数或过程清单及本文件历史修改记录等。
/*** Copy Right Information : Neusoft IIT* Project : eTrain* JDK version used : jdk1.3.1* Comments : config path* Version : 1.01* Modification history :2003.5.1* Sr Date Modified By Why & What is modified* 1. 2003.5.2 Kevin Gao new**/在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；输入、输出及返回值说明；调用关系及被调用关系说明等/*** Description :checkout 提款* @param Hashtable cart info* @param OrderBean order info* @return String*/public String checkout(Hashtable htCart,OrderBean orderBean)throws Exception{}javadoc注释标签语法@author 对类的说明 标明开发该类模块的作者@version 对类的说明 标明该类模块的版本@see 对类、属性、方法的说明 参考转向，也就是相关主题@param 对方法的说明 对方法中某参数的说明@return 对方法的说明 对方法返回值的说明@exception 对方法的说明 对方法可能抛出的异常进行说明3、命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。
（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性）较短的单词可通过去掉元音形成缩写；要不然最后自己写的代码自己都看不懂了，那可不行。
较长的单词可取单词的头几发符的优先级，并用括号明确表达式的操作顺序，避免使用默认优先级。
使用匈牙利表示法Package 的命名Package 的名字应该都是由一个小写单词组成。
package com.neu.utilClass 的命名Class 的名字必须由大写字母开头而其他字母都小写的单词组成，对于所有标识符，其中包含的所有单词都应紧靠在一起，而且大写中间单词的首字母。
public class ThisAClassName{}Class 变量的命名变量的名字必须用一个小写字母开头。
后面的单词用大写字母开头userName , thisAClassMethodStatic Final 变量的命名static Final 变量的名字应该都大写，并且指出完整含义。
/***DBConfig PATH**/public static final StringDB_CONFIG_FILE_PATH =com.neu.etrain.dbconfig；参数的命名参数的名字必须和变量的命名规范一致。
数组的命名数组应该总是用下面的方式来命名：byte[] buffer；而不是：byte buffer[]；方法的参数使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字：SetCounter(int size){this.size = size;}4、文件样式所有的 Java(*.java) 文件都必须遵守如下的样式规则：版权信息版权信息必须在 java 文件的开头，比如：/** Copyright ? 2000 Shanghai XXX Co. Ltd.* All right reserved.*/其他不需要出现在 javadoc 的信息也可以包含在这里。
Package/Importspackage 行要在 import 行之前，import 中标准的包名要在本地的包名之前，而且按照字母顺序排列。
如果 import 行中包含了同一个包中的不同子目录，则应该用 * 来处理。
package hotlava.net.stats;import java io.*;import java.util.Observable;import hotlava.util.Application；这里 java。
io.* 使用来代替InputStream and OutputStream 的。
Class接下来的是类的注释，一般是用来解释类的。
/*** A class representing a set of packet and byte counters* It is observable...
转载请注明出处51数据库 » java软件设计原则
