设计迷踪:给JAVA设计开发新手的一些建议和意见(一)

scud(飞云小侠) 2005-7-23 http://www.jscud.com 转载请注明作者

【概述】
-------
在工作中,作为一个程序员或者一个设计师,总是要设计一些函数库或者一个框架,当然最经常的还是做项目,即使是一个项目,也会被经常改动,甚至交给别人改动.
当你做这些工作的时候,你的这些成果都是要给别人了解使用的,或者说给以后的你使用的,为了别人的方便或者为了自己的方便,我们要尽可能做好设计.

【放正心态,任何东西都是不断发展的】
----------------------------------

技术是日新月异的,每一天都有新的技术出来,正所谓"山外有山,人外有人",每一个新的轮子出来,都可能比你要设计的轮子好,所以在设计的时候,应该了解一下是否已经有了类似的轮子,是否要设计一个新的轮子.
即使你的轮子已经设计好了,也不好认为自己的轮子一定比别人的轮子好,虽然你的轮子可能更适合你的实际使用.
技术在不断的发展中,你以及你的朋友/同事都在不断进步,"士别三日,当刮目相看",所以不要认为你的水平一定比别人高,"尺有所短,寸有所长",所以别人对你的函数库/框架提出意见,提出疑问的时候,请不要惊奇,不要反感,不要认为别人在"挑刺",也许你的函数库/框架早就不适合当前的发展了.


态度决定一切.你的领导或许更重视这一点.


【必要的组成部分:单元测试,文档,实例,手册etc】
--------------------------------------------

单元测试,文档,API Doc,手册,演示程序,Change Log,Readme,build.xml等等

有一天别人使用了你设计的函数库/框架,当你升级后,原来的项目却不能工作了,经过一天的调试,你终于找到了原因,原来是不小心写错了一个东西.
你肯定不希望上述的事情发生,那么请你写单元测试吧,这样既不浪费自己的时间,也不耽误别人的工作,何乐而不为.你花在写单元测试的时间/带来的乐趣和你升级后改正莫名其妙的错误的时间和苦恼相比,肯定更有价值.你看到单元测试的绿条,难道不感到高兴吗?!
如果你不能保证你的程序修改没有错误,不要指望你的同事认为你的错误是可以容忍的,他们在心里早就开始骂你了,呵呵.写单元测试吧

看看任何一个知名的框架,都包含完善的文档,单元测试,示例程序,用户手册,那么请你也包含这些吧.哦,对了,请详细地写好JavaDoc,它很重要.

使用你的框架/函数库的人如果到处去找使用方法,去找某个类(但是他不知道是否有这个类),那么说明你的文档没有到位.如果你希望别人使用你的这个类或者功能,那么请写好文档,不要指望别人去读你的源码然后就能理解它是干什么用的.

如果你做到这些,那么你的函数库/框架也有了"知名"的前提,难道不是吗?如果没有,我想是没法让别人更好地使用的.

对了,有了这些东西,还要有一个良好的目录组织,这个也可以参考别的框架的组织方式.


【借鉴成熟的设计,参考已有的项目】
--------------------------------

1.要做一个新的东西,没有想法.不要惊讶,我肯定先找一个现有的东西来借鉴.

当然前提是不要重新发明轮子,或者是你有充分条件要重新发明一个轮子.
Struts,WebWork,Spring等等都是成熟的框架,不管你使用起来是否符合你的习惯.
在你成为大师之前,你的设计思想估计前人都已经提出并实践过了,所以要勇敢地去借鉴."站在巨人的肩膀上"我们能更近一步.

例如我们厌倦了在访问数据库时使用如下的代码:

try
{
//your code here
}
catch(Exception e)
{
//catch Exception
}
finally
{
//must do something
}

我们就可以借鉴Spring框架的JdbcTemplate类,看看它是如何利用回调函数来处理的.

我们使用hibernate时是不是也会使用类似上面的代码,那么可以参考Spring框架的HibernateTemplate.

借鉴也是一种捷径.

警告:借鉴但不要抄袭,借鉴代码要注明来源,尊重他人也是尊重自己.


2.在实际的项目中,往往可以参考已经有的项目来做自己的设计.

例如做一个网站,我不知道如何访问数据库,如何布局,如何分层,那么我们可以参考已经有的网站程序,看看别人是如何利用SiteMesh或者tiles布局,如何使用Hibernate来访问数据库或者使用已经封装好的JDBC类来访问数据库,如何利用Struts,WebWork或者其他访问来分层.


【遵守约定俗成的一些做法】
-------------------------

为了使别人更方便地使用你的东西,那么在设计一些通用的函数或者类的时候,请遵守通用的做法,不要与众不同,除非你的内部实现确实与众不同.

例如实现一个类似ArrayList的类,那么请不要这样写:

public int count()
{
return list.size();
}
public Item getItem(int i)
{
return list.get(i);
}

而应该这样:

public int size()
{
return list.size();
}
public Item get(int i)
{
return list.get(i);
}

当然每个人都有自己的想法,如果你非常认为你原来的方式比普通的好,那么请提供2套方式供别人选择.它不会给你带来麻烦,只是一个一看就懂的做法,不用怀疑,这样做有好处.

很多类的设计都有一些约定俗成的做法,那么在你设计一个新类的时候,先借鉴一下吧,多看看JDK的源码/文档,看看别人是怎么实现的.这更有助于推广你的成果.

【不要迷信权威】
---------------

在使用已有的框架或者函数库时,不要认为所有的东西都是正确的或者是最好的最好,肯定不是.没有完美的东西,已经存在的东西在设计的时候因为种种局限或者因为作者的水平,对现在来说肯定存在不合理的设计,或者过于理想化的设计,而不能满足实际情况.

不迷信权威,才能到达新的境界.

【不要轻易排斥,不了解就不要草率发表意见,要严谨】
------------------------------------------------

在网上经常看到.Net和Java的比较/火拼,或者是Struts VS Webwork或者是其他等等,非常之多.经常看到的是一方对对方的东西不甚了解,就开始批评,结果说不到点子上,反而被嘲笑一番.
几种技术的比较有时候是必要的,例如技术选型的时候.但是如果一些对这些技术根本不了解的人来选型,来评判,你能对结果信服吗?
存在就是合理,任何技术都有其存在的理由,虽然有些东西早就过时了,但是在当时它也是应运而生的.
几种技术,都是来解决同样的问题,但是问题也有很多方面,解决方式也有很多种,每个人的想法也都不一样,思路也不一样,所以没有绝对符合要求的技术,但是应该有符合你的技术,不符合你的技术不等于也不满足别人的要求.所以不要轻易排斥别的东西.

在做技术比较的时候,如果你不了解,那么请不要轻易发表意见,至少你可以亲自去了解,去实践之后在发表你的意见岂不是更好.

在发表意见的时候,也要严谨,不要轻易下结论,要经过求证,否则一旦错误只会让对手笑话,让你的同事看不起你.例如你说Hibernate3不支持jdk1.3,那么最好去好好找到你的证据,否则就会成为错误.(Hibernate3支持jdk1.3)

作为一个技术人员,严谨应该是我们的习惯之一,无论做开发还是做设计.