开发学院WEB开发Jsp 给JAVA设计开发新手一些建议和意见(2) 阅读

给JAVA设计开发新手一些建议和意见(2)

 2008-01-05 18:17:58 来源:WEB开发网   
核心提示:【处理好你的异常】异常处理是java编程中非常重要的一个部分,建议在使用异常之前阅读或者,给JAVA设计开发新手一些建议和意见(2),下面从书中摘出几条建议:*绝对不要忽略异常*千万不要隐藏异常****仅在不正常的情况下使用异常*对可恢复的情况使用可检查异常,对程序错误使用运行时异常(RunTimeException)

  【处理好你的异常】
  
  异常处理是java编程中非常重要的一个部分。建议在使用异常之前阅读或者。
  
  下面从书中摘出几条建议:
  
  *绝对不要忽略异常
  
  *千万不要隐藏异常***
  
  *仅在不正常的情况下使用异常
  
  *对可恢复的情况使用可检查异常,对程序错误使用运行时异常(RunTimeException)
  
  *给方法引发的异常做文档
  
  *在具体信息里面包括失败捕捉信息
  
  *使用finally避免资源泄漏
  
  *。。。。
  
  在这里非凡提出的是,在开发中要非凡处理NULL的情况,否则经常引发NullPointException异常,在Java里这是一个最令人头疼的异常了。
  
  假如你的程序因为一个NULL值,而报了几十个NullPointException的话,不但得让人烦死,而且还非常难以找到错误所在。所以在Java中一定要注重这个问题。
  
  假如你的函数不答应Null值,那么可以截获它,抛出一个异常,或者给客户更友好的提示,难道不好吗?
  
  让我们来看一个例子:
  
  public String getName(User aUser)
  
  {
  
  //假如aUser为Null,会发生什么情况
  
  return aUser。getName();
  
  }
  
  很明显,假如参数为Null,就会抛出异常。应该改为:
  
  public String getName(User aUser)
  
  {
  
  if(null=aUser)
  
  {
  
  return "";
  
  }
  
  else
  
  {
  
  return aUser。getName();
  
  }
  
  }
  
  或者你要求参数不能为空,还可以抛出一个异常,强制使用者不能传入空值。
  
  还有经常被忽略的是RunTimeException和普通异常的区别,在Java中,这是一个非凡的异常类,程序中假如碰到这个异常,用户可以不截获它,而假如是其他的普通异常,就不许要截获它。我们的代码经常这么写:
  
  try
  
  {
  
  //your code here
  
  }
  
  catch(Exception e)
  
  {
  
  //do warn
  
  }
  
  这样写的话,就截获了所有异常,当然也包括了RunTimeException。 在很多情况下,这是不合适的处理方式,我们只应截获必要的异常,而应该忽略RuntimeException。
  
  关于RunTimeException,在SPRing中还有更好的利用方式,建议阅读Spring框架中在事务中对异常的处理代码,例如对Jdbc抛出的SqlException的转换。
  
  关于异常处理,我提出几点建议:
  
  *捕捉异常而且再次抛出时要包含原来的异常信息
  
  *不要忘了RunTimeException,除非必要,否则不要用catch(Exception e)的方式捕捉所有异常。
  
  *不要用异常做流程控制,异常的性能代价比较高昂。(对此,可能有人不同意。此处不具体讨论)
  
  *不要把异常处理都抛给别人,本函数有能力处理的就不要抛出。
  
  在此建议读者具体阅读或者。
  
  【过度依靠】
  
  在定位错误的时候,经常碰到浏览了七 八个文件还是没有找到什么地方执行了真正需要的函数,这个时候就非常郁闷。A调用了B,B调用了C,C调用了D。。。。。。让人找不到北
  
  面对这样的程序,存在的问题不仅仅是定位错误麻烦,而且假如需要维护这样的函数库/框架,恐怕你的有非常高的统御能力才行,否则打死我也不去维护。
  
  那么我们自己最好不要写这样的程序出来给人用。
  
  【滥用接口】
  
  现在流行"面对接口编程",这本身本来是不错,但是滥用接口的现象却经常发生。
  
  "面向接口",于是所有的类都有一个对应的接口,接口的函数声明和类一模一样,而且一个接口只有一个类来实现它。这样的面向接口有什么意义哪? (为了用Spring的事务的情况除外)
  
  根据"迪比特法则(Law of Demter)",一个对象应当对其他对象有尽可能少的了解。一个接口内应该只定义对方所需要的方法,而不要把一些没用的方法声明放在接口里面。
  
  例如如下一个类:
  
  public class MyCounter
  
  {
  
  private int n1;
  
  private int n2;
  
  public MyCounter(int n1,int n2)
  
  {
  
  this。n1=n1;
  
  this。n2=n2;
  
  }
  
  public void setN1(int n1)
  
  {
  
  return this。n1 = n1;
  
  }
  
  public void setN2(int n2)
  
  {
  
  return this。n2 = n2;
  
  }
  
  public int getN1()
  
  {
  
  return n1;
  
  }
  
  public int getN2()
  
  {
  
  return n2;
  
  }
  
  public int getResult()
  
  {
  
  return n1 + n2;
  
  }
  
  }
  
  我们可以看到,这个类的主要目的是得到计算结果,所以正确的接口应该类似:
  
  public interface Counter
  
  {
  
  int getResult();
  
  }
  
  但是很多情况下,经常是这样的接口:
  
  public interface Counter
  
  {
  
  int getResult();
  
  int getN1();
  
  int getN2();
  
  void setN1(int n1);
  
  void setN2(int n2);
  
  }
  
  我们想一想,这样做有2个后果:
  
  1.除了getResult之外,其他的函数我们根本用不到,所以是多余的。
  
  2.假如我们要自己实现一个Counter,假如接口中仅仅定义了getResult,我们仅仅需要实现它就可以了。我们自己的类可能是多个数运算,有乘除加减等等各种运算,参数也有可能是一些数组。但是假如按照第二种方法声明接口的话,我们就必须实现后面的四个方法,假如这样的话,实现这样东西不仅没用,而且浪费时间。我们恐怕要大声骂娘了吧。
  
  所以,接口有好的作用,但是不要滥用。
  
  ■ 假如你的接口永远只有一个类实现,那么可能就没有必要用接口。
  
  ■ 你的接口只需要声明别人用到的函数即可。

Tags:JAVA 设计开发 新手

编辑录入:爽爽 [复制链接] [打 印]
[]
  • 好
  • 好的评价 如果觉得好,就请您
      0%(0)
  • 差
  • 差的评价 如果觉得差,就请您
      0%(0)
赞助商链接