深入理解抽象类和接口的区别

深入理解abstract class和interface
城市WebClub
2003-12-10 13:51:19
5816 次浏览
abstract class和interface是Java语言中对于抽象类定义进行支持的两种机制，正是由于这两种机制的存
在。

从语法定义层面看abstract class和interface
在语法层面，Java语言对于abstract class和interface给出了不同的定义方式，下面以定义一个名为Demo 的抽象类为例来说明这种不同。

使用abstract class的方式定义Demo抽象类的方式如下：
abstract class Demo ｛
abstract void method1();
abstract void method2();
…
｝
使用interface的方式定义Demo抽象类的方式如下：
interface Demo {
void method1();
同样，如果不能在抽象类中定义默认行为，就会导致同样的方法实现出现在该抽象类的每一个派生类中，违反了"one rule，one place"原则，造成代码重复，同样不利于以后的维护。

因此，在abstract class和interface 间进行选择时要非常的小心。

从设计理念层面看abstract class和interface
上面主要从语法定义和编程的角度论述了abstract class和interface的区别，这些层面的区别是比较低层次的、非本质的。

本小节将从另一个层面：abstract class和interface所反映出的设计理念，来分析一下二者的
区别。

作者认为，从这个层面进行分析才能理解二者概念的本质所在。

前面已经提到过，abstarct class在Java语言中体现了一种继承关系，要想使得继承关系合理，父类和派生类之间必须存在"is a"关系，即父类和派生类在概念本质上应该是相同的（参考文献〔3〕中有关于"is a"关系的大篇幅深入的论述，有兴趣的读者可以参考）。

对于interface 来说则不然，并不要求interface的实现者和interface定义在概念本质上是一致的，仅仅是实现了interface定义的契约而已。

为了使论述便于理解，下面将通过一个简单的实例进行说明。

考虑这样一个例子，假设在我们的问题领域中有一个关于Door的抽象概念，该Door具有执行两个动作open 和close，此时我们可以通过abstract class或者interface来定义一个表示该抽象概念的类型，定义方式分别
解决方案一：
简单的在Door的定义中增加一个alarm方法，如下：
abstract class Door {
abstract void open();
abstract void close()；
abstract void alarm();
}
或者
interface Door {
void open();
void close();
void alarm();
}
既然open、close和alarm属于两个不同的概念，根据ISP原则应该把它们分别定义在代表这两个概念的抽象类中。

定义方式有：这两个概念都使用abstract class方式定义；两个概念都使用interface方式定义；一个概念使用abstract class方式定义，另一个概念使用interface方式定义。

显然，由于Java语言不支持多重继承，所以两个概念都使用abstract class方式定义是不可行的。

后面两种方式都是可行的，但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。

我们一一来分析、说明。

如果两个概念都使用interface方式来定义，那么就反映出两个问题：1、我们可能没有理解清楚问题领域，AlarmDoor在概念本质上到底是Door还是报警器？2、如果我们对于问题领域的理解没有问题，比如：我们通过对于问题领域的分析发现AlarmDoor在概念本质上和Door是一致的，那么我们在实现时就没有能够正确的揭示我们的设计意图，因为在这两个概念的定义上（均使用interface方式定义）反映不出上述含义。

如果我们对于问题领域的理解是：AlarmDoor在概念本质上是Door，同时它有具有报警的功能。

我们该如何来设计、实现来明确的反映出我们的意思呢？前面已经说过，abstract class在Java语言中表示一种继承关系，而继承关系在本质上是"is a"关系。

所以对于Door这个概念，我们应该使用abstarct class方式来定义。

另外，AlarmDoor又具有报警功能，说明它又能够完成报警概念中定义的行为，所以报警概念可以通过
abstract class和interface是Java语言中的两种定义抽象类的方式，它们之间有很大的相似性。

但是对于它们的选择却又往往反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理，因为它们表现了概念间的不同的关系（虽然都能够实现需求的功能）。

这其实也是语言的一种的惯用法，希望读者朋友能够细细体会。

在保留原出处的情况下，欢迎转载!
J2EE与电子商务应用
J2EE与电子商务应用□凯思信得王昱
电子商务的发展对传统的Web技术提出了强有力的挑战，由于电子商务的内部逻辑复杂，安全性要求苛刻，商务形式发展变化快，这就要求Web技术提供足够的复杂度和灵活性以适应电子商务的需求。

J2EE（Java 2 Enterprise Edition）技术于是脱颖而出，并且日益完善，成为电子商务的主要开发平台。

它是一个技术标准，并不是一个产品。

符合J2EE标准的产品有BEA 公司的Weblogic、Sun公司的NetDynamics、IBM的Websphere,还有包括著名数据库厂家Informix、Oracle、Sybase在内的上百个产品（具体信息请参见链接/industry.html）。

它们基本上都是应用服务器产品，因此J2EE平台通常指的是应用服务器的平台。

但是，在Web服务器之后架设应用服务器，会对Web服务的响应速度带来较大的影响(尽管上述大多数产品本身都可用作Web服务器，但在内部结构上，Web服务器和应用服务器仍是分开的)。

有经验的J2EE开发人员都会知道，要适应同等数量的用户，J2EE 平台需要更高的硬件配置。

按理来说，响应速度是Web服务质量的重要方面，既然J2EE 平台降低了响应的速度，那它究竟带来了什么好处使电子商务平台的开发者如此青睐它？
面向对象的编程语言
J2EE平台是建立在Java语言基础上的，Java是真正面向对象的语言，具有丰富的数据类型和强大的功能，能完成几乎任何复杂的功能，这是一般Web CGI编程语言所无法比拟的。

面向对象的设计方法，不但可以设计庞大而复杂的系统，还可以使Web应用程序具有良好的扩充性和维护性，能够方便地实现国际化和本地化的功能，深受Web 开发人员的喜爱。

平台独立的特性
J2EE平台独立的特性包括两个方面，一是Java语言本身的平台独立性，二是J2EE 标准的平台独立性。

Java是一个跨平台的语言，在任何平台上，只要有Java Virtual Machine，就能在不同平台上执行同一个Java程序。

例如，BEA的Weblogic 在任何平台下都是同样的产品，因为它是100％纯Java的。

另外，J2EE标准的平台独立性使得任何符合J2EE标准的应用服务器之间可以共用标准的组件。

也就是说，在Weblogic下开发的组件也能用于Websphere中。

这样，在电子商务应用的开发中可以任意选择或购买符合标准的通用组件，加快开发的过程。

J2EE的平台独立性使程序的移植变得轻松简单。

在J2EE中，你可以把一个Weblogic ＋Oracle的应用程序移植到Websphere＋Informix上，不需要改动任何源码，只需要进行一些不算复杂的配置即可，这也是J2EE为何如此流行的主要原因之一。

高性能的服务器端编程语言
Java以前给人的印象是功能强而性能较差的解释执行语言，实际上从Java 1.2 开始，特别是Java 1.3，性能有了飞跃，即时编译技术(JIT)使Java的执行效率大大提高。

由此可见，Java是服务器端编程的优秀语言。

但笔者认为，Java不适合客户端的应用，比如Applet。

因为各种桌面浏览器的JVM版本可能不同，安全设置也不尽相同，会造成应用程序的不通用；而在服务器端，一切尽在你的掌握之中。

J2EE提供了标准的系统框架和服务
J2EE平台提供了事务处理、对象生存控制、状态维持、并发控制、安全检测、资源共享等系统服务。

需要这些服务的代价并不高，不用编程，而只要通过简单的配置就行。

这使电子商务开发者从繁琐的系统设计中解脱出来，将精力主要放在商业逻辑上，提高应用的质量和加快开发的速度。

标准化的框架结构是以分布式的多层应用体系为基础，使J2EE应用天然就具有可扩
充性和可维护性(如图)。

在系统的任意层面中可以增加新的功能，而不影响原有的系统，这种优点是平时需要花大量的设计、实现的功夫才能达到的，而使用J2EE平台可自然获得。

适合团体开发
J2EE的构架非常适合团体开发的模式。

标准的结构自然将应用分成表现层、企业逻辑层和数据层。

可以使企业中的美工、系统分析员、编程人员各司其职，发挥各人的长处。

特别是J2EE构架通用的MVC (Model，View，Control)模式，能够将系统各个层面的功能独立开来，使得一个美工修改界面根本不需要和Java程序员打交道。

这种构架非常适合团队开发的模式，提高工作的效率。

可控性好
J2EE安全控制和状态控制机制非常完善，这种控制机制使得整个应用拥有统一的状态转换规则。

这样，不会让用户进入到不该进入的页面而引起状态的混乱，增加了系统的安全性。

在J2EE中，状态的可控性使电子商务的开发更加简单和可靠，为顾客提供更好的服务。

与其他资源的集成
一个电子商务的应用很大程度上可能建立在原有的信息系统之上，这就要求应用开发平台能够和遗留系统具有很好的集成能力。

J2EE平台以其丰富的系统功能，通过JDBC、JTA、JMS、XML、 JNDI、CORBA等API可以与几乎所有关系型数据库、事务处理服务器、消息处理服务器、目录服务器和邮件服务器等进行无缝的集成，完美地结合成一个整体，保护原有的投资，并且为将来的发展留出广阔的空间。

J2EE有如此多的优势，一定就适合任何电子商务的模式吗?其实不然，对于用户来说，在选择J2EE平台时，一定要考虑以下几个问题：
是否有足够的技术力量
J2EE虽然功能强大，可是它的学习曲线长，对设计人员的要求很高，需要将整个应用设计成多个抽象的逻辑的层次和大量独立的对象，以及层次之间和对象之间的接口和协议，这都需要较强的技术团体和熟练的编程人员。

另外，Java语言作为Web服务编程语言也有它的缺点：大部分程序需要编译（JSP 除外），这比起各种CGI Script语言来说是很不方便的，修改、调试、维护工作量都很大。

整个J2EE技术不是一个“循序渐进”的系统平台。

J2EE从一开始就将它所有的技术深度展现给技术人员，面向对象的设计和编程技术也并非短时间就能掌握的，就连一些简单的应用配置文件也是XML格式的。

因此要找一些asp程序开发者容易，找J2EE 工程师可就难了。

是否真需要分布式平台
各种J2EE的产品都给大家展示了一幅分布式平台的美好画面：你可以在多台不同的服务器上运行同一个服务应用，能将各种不同J2EE对象分布到不同的服务器上，进行负载均衡，而不破坏应用的整体完整性。

这样就能够大大提高响应性能，并且大大提高系统容错能力和高可用性，因为无论哪一台服务器出现了故障，都会有其他的机器接替它的工作。

但是，这对于你未必实用。

首先，您要确认是否有多台服务器可供运行应用服务器。

即使有，也不一定就能得到很好的性能。

因为大多数Web应用都是建立在数据库管理系统之上的，系统的背后一定运行着Oracle8i、Informix Foundation 2000、 Sybase或SQL Server。

当有多台应用服务器时，系统的性能瓶颈一定会在数据库系统。

如果数据库系统性能下降或瘫痪，应用服务器将无法发挥作用。

是否有足够的经费运行J2EE
运行J2EE的电子商务平台，除了要多负担J2EE平台的费用以外，还要负担硬件平台的费用。

因为J2EE的运用会使整个Web响应的速度降低，这主要是因为大量的远程组件调用的延时和大量的中间对象的维护。

因此，对于一些速度是关键因素的Web 应用，不得不提高硬件平台的质量或数量来提高整个系统的性能。

因此在选择J2EE平台时，一定要考虑清楚什么是对自己最重要的。

如果是系统的开放性、可维护性、可移植性很重要，并且用户状态维护很复杂，那么选J2EE肯定会事半功倍；如果是响应的速度、开发的时间和开发的费用是最重要的，传统的Web开发系统就已经足够了。

另外，使用J2EE平台时，深藏在服务中的动态页面是不会被各种搜索工具查到的，所以，以广告为主要业务的应用大可不必使用J2EE平台。