J2ee程序中的面向对象设计(OO Design Recommenda…

2008-02-23 09:13:07来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

面向对象程序设计比任何具体技术都重要。但是在使用种种模式的时候,也要防止过度设计,增加不必要的复杂性、浪费时间和经费。

1、使用接口降低程序的耦合性(Achieving Loose Coupling with Interfaces)

虽然面向接口编程回比直接面向具体类编程增加一点点的复杂性,但是带来的好处却是巨大的。

1)、可以改变实现而不改变调用的代码。这使我们可以重新实现程序的一部分,而不用去修改其它部分。
2)、可以自由的实现接口,并促进重用。
3)、必要的时候可以写出一个简单的测试实现,或者Stub实现。

2、尽量使用结合,而不是继承(Prefer Object Composition to Concrete Inheritance)

结合提供了更大的灵活性,它可以在运行时改变程序的行为。Strategy和State模式都是基于这一理论的。

3、模版模式(The Template Method Design Pattern)

模版模式是直接类继承的一种正确使用。但你知道一些算法的步骤,但是不清楚他们的具体操作就可以使用模版模式,将具体的操作留到以后实现。依赖倒转 (IOC/Inversion of Control)就是模版模式的一种使用,它通过模版模式,让框架代码调用用户自己的代码,而不是正常的那种用户代码去掉用框架的代码。模版模式特别适用 于框架设计。

4、策略模式(The Strategy Design Pattern)

策略模式比模版模式稍微复杂了一点,但是提供了更大的灵活性。但存在以下的情况时就应该使用策略模式:
1)、当算法的所有的步骤都可变,而不是仅仅有几个的时候
2)、当实现具体步骤的类有一个特定的继承层次的时候
3)、当实现具体步骤的类需要和其他类相关联的时候
4)、当这些步骤需要在运行时改变的时候
5)、当算法特定步骤的实现会持续增加的时候

5、使用回调增加扩展性(Using Callbacks to Achieve Extensibility)

回调是策略模式的一种特殊使用,他可以实现特殊的操作,而将错误处理、Logging放进框架中。如:public interface RowCallbackHandler {void processRow(ResultSet rs) throws SQLException;}
public void query(String sql, RowCallbackHandler callbackHandler)
throws JDBCSqlException {
try {
.....
while (rs.next()) {
callbackHandler.processRow(rs);
}
....
} catch (SQLException ex) {
....
} finally {
....
}
}
回调的优点:
1)、可以集中进行错误处理和资源的获取、释放。这样可以让你实现更灵活、更强大的错误处理,还不增加工作量。
2)、于底层实现细节无关。
3)、一个工作流程,可以通过不同的实现,完成不同的工作。充分实现了代码的重用。
回调的缺点:
1)、这种模式,不能让你直接看到被调用的代码。这可能让代码变得不容易理解和维护。
2)、必须创建一个回调的接受接口或类。
3)、不知道书上再写什么。
这个模式特别适用于回调接口非常简单的情况,最好回调接口只有一个方法,这样可以通过inner类的形式实现。

6、观察者模式(The Observer Desing Pattern)

只有当系统中出现了需要了解工作流程的松散监听者(Loosely coupled Listener)时,才需要使用这种模式。如果我们过度的使用了他,就会导致业务被事件(event)发布的代码所淹没。只有重要的工作流程才有可能需 要实现他。监听者(Listener)必须能够快速的返回,并且线程安全。不能及时放回的监听者可能阻塞这个程序。

七、完善方法的参数(Consider Consolidating Method Parameters)

有些时候,我们需要将多个方法参数压缩到一个对象中,这样可以简化代码。最大的好处就是可以改变方法的参数,但是不用改变调用的代码,并且能过简单的实现方法的默认参数。缺点就是可能参数大量的小对象,这些对象将消耗堆的空间。

八、异常捕捉(Exception Handling – Checked or Unchecked Exceptions)

Java将异常分为:Checked exceptions,Unchecked(Runtime) exceptoins。Checked exceptions继承与java.lang.Exception,不许声明和捕捉;Runtime exceptions继承与java.lang.RuntimeException,不用生命,可以不捕捉。(C ,C#中的异常都相当于 Unchecked Exceptions)
虽然传统的观点认为尽量使用Checked Exception,不用Runtime Exception。但是作者不怎么认为,理由如下:
1)、太多代码
2)、难于阅读
3)、无休止的包装Exception
4)、易变得方法声明
5)、导致不必要的关联底层实现。
作者相信,当一个函数返回两个可选返回值得一个的时候,就需要去判断,最好编译器能过强制判断。那就是使用Checked Exception,其他的情况,作者认为Checked Exception被过分强调了。
注:Checked异常要比使用return codes强,它能够强迫用户去捕捉异常。但是Checked Exception不适合用于表示致命的错误,和调用者不需要去捕捉的异常。J2EE容器有责任去捕捉并记录Runtime Exception。
每当需要决定使用哪一种异常的时候,都需要问自己下面的几个问题:

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Struts Spring Hibernate上传下载 --之一

下一篇:第六章 Java类文件(Chapter Six: The Java Class File)