您的位置:首页 > 其它

接口和抽象类

2015-10-20 20:42 423 查看
接口interface的作用


接口是对于行为的抽象,在小项目、小设计中接口带来的好处可能不会特别明显,但是项目一旦庞大起来,接口的优势就很明显会体现出来了:

1、对于一个庞大的项目,从设计的角度来说,接口的存在可以帮助理清楚业务,利用接口不仅可以告诉开发人员需要实现哪些业务,而且也将命名规范限制住了,从而防止开发人员随便命名导致项目组别的开发者无法看明白:

public interface StudentOperate
{
void addStudent(String name, int age, String phone);
boolean deleteStudent(int id);
void qureyStudent();
boolean updateStudent(int id, String name, int age, String phone);
}


这么定义接口,意味着这个接口必须按照这个规范来,接口干什么用的,接口里面有哪些功能,事先已经理清楚业务,只是没有实现罢了。不管是项目内调用,还是分布式系统的分层调用,都按照指定的接口名、接口请求、接口响应来,相当于是定了一个规范。

2、弥补了Java类单继承的不足,这个很好理解,类的多实现:

public class MultiClass<E> implements Cloneable, Serializable, Iterator<E>
{
private static final long serialVersionUID = 1L;

public boolean hasNext()
{
return false;
}

public E next()
{
return null;
}

public void remove()
{

}
}


同样,接口也可以多继承:

public interface MultiInterface<E> extends Cloneable, Serializable, Iterator<E>
{

}


这样,实现类就是所有父接口的子类。

3、降低代码的耦合性。由于Java多态的特性,接口的引用是可以接受子类对象的,用实现的子类实例化声明的接口后,就可以通过接口调用子类重写的方法。也就是说调用接口的地方,和实现接口的地方是无关的,增加或者删除了接口,都不需要去改动调用接口的地方,这就大大缩减了代码量、增加了代码的扩展性、灵活性,比如没有接口的时候我们是这么写的:

public class ClassA
{
public void print()
{

}


public class ClassB
{
public void print()
{

}
}


public class Invoke
{
public void print(ClassA ca)
{
ca.print();
}

public void print(ClassB cb)
{
cb.print();
}
}


这在类多了之后是非常麻烦的,invoke类将重载更多的print方法,但是用接口就方便多了:

public interface Print
{
void print();
}


public class ClassA implements Print
{
public void print()
{

}
}


public class ClassB implements Print
{
public void print()
{

}
}


public class Invoke
{
public void print(Print p)
{
p.print();
}
}


这样就方便多了,不管Print的子类如何增加,调用的地方Invoke的print方法都不需要作任何的改动,这就是解耦,这也就是接口的作用。当然,有人可能会说,继承一个普通类或者继承一个抽象类也有这种功能嘛,对的,但是:

(1)继承的关系太死了,并不灵活

(2)类可以实现多个接口,但却只能继承一个类

(3)接口属于一种完全的抽象,不管是继承普通类还是继承抽象类都达不到这种特性

接口和抽象类的区别

1、接口和抽象类的概念是不一样的。接口是对动作的抽象,表示的是这个对象能做什么,比如人可以吃东西、狗也可以吃东西,只要有相同的行为;抽象类是对根源的抽象,表示的是这个对象是什么,比如男人是人、女人也是人

2、可以实现多个接口,只能继承一个抽象类

3、接口中只能定义抽象方法,抽象类中可以有普通方法

4、接口中只能有静态的不能被改变的数据成员,抽象类可以有普通的数据成员

以上是从语法和编程的角度来看接口和抽象类的区别的,下面从设计理念的角度来分析一下二者个区别。考虑这样一个例子,假设在我们的问题领域中有一个关于Door的抽象概念,该Door具有两个动作open和close,此时我们可以通过abstract class或者interface来定义一个表示抽象概念的类型,定义方式分别为:

abstract class Door
{
abstract void open();
abstract void close();
}


interface Door
{
void open();
void close();
}


具体的Door类型可以继承abstract class或者实现interface。这样看起来好像使用abstract class和interface没有大区别。但是如果现在要求Door还要具有报警的功能,该如何设计呢?

下面罗列可能的解决方案,并从设计理念层面对这些不同的方案进行分析。

方案一

简单地在Door的定义中增加一个alarm方法:

abstract class Door
{
abstract void open();
abstract void close();
abstract void alarm();
}


interface Door
{
void open();
void close();
void alarm();
}


那么具有报警功能的AlarmDoor的定义方式如下:

class AlarmDoor extends Door
{
void open(){...}
void close(){...}
void alarm(){...}
}


class AlarmDoor implements Door
{
void open(){...}
void close(){...}
void alarm(){...}
}


不得不说这是一种糟糕的方案,因为这种方案违反了面向对象设计中的一个核心原则ISP,在Door的定义中把Door概念本身固有的行为方法和另外一个概念"报警器"的行为方法混在了一起,这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为"报警器"这个概念的改变而改变(比如修改alarm方法的参数),反之亦然。

方案二

既然open、close和alarm属于两个不同的概念,根据ISP原则应该把它们分别定义在代表这两个概念的抽象类中。定义方式有:

1、这两个概念都用abstract class定义

2、这两个概念都用interface定义

3、一个概念用abstract class定义、一个概念用interface定义

显然,由于Java不支持多重继承,所以两个概念都用abstract class方式定义是不可行的。可能有人会说哦,让门的抽象方法A继承报警的抽象方法B,类再继承抽象方法A不就好了。问题是如果我有另外一个门,有防水功能怎么办?抽象方法A还能继承报警的抽象方法D吗?所以一开头就说了,继承的方式太死了,是什么就是什么。接口就不同了,由于类可以实现多个接口,所以可以任意组合。

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

如果两个概念都用interface方式定义,那么就反映出两个问题:

1、我们可能没有理解清楚问题领域,AlarmDoor在概念本质上到底是Door还是报警器?

2、如果我们对于问题领域的理解没有问题,那么我们在实现时就没有能够正确地揭示我们的设计意图,因为这两个概念的定义上反映不出上述含义

如果我们对于问题领域的理解是:AlarmDoor在本质上是Door,同时它具有报警功能,那么我们该如何来设计和实现来明确反映出我们的意图?前面已经说过,abstract class在Java语言中表示一种继承关系,而继承关系在本质上是"is a"的关系。所以对于Door这个概念,我们应该使用abstract class方式来定义。另外AlarmDoor又具有报警功能,说明它又能完成报警概念中定义的定位,所以报警概念可以通过interface方式定义。如下:

abstract class Door
{
abstract void open();
abstract void close();
}


interface Alarm
{
void alarm();
}


class AlarmDoor extends Door implements Alarm
{
void open(){...}
void close(){...}
void alarm(){...}
}


这种实现方式基本上能够明确反映出我们对于问题领域的理解,正确地解释我们的设计意图:AlaramDoor是Door并且它有Alarm的功能。当然这是建立在对问题领域的理解上的,比如:如果我们认为AlarmDoor在概念本质上是报警器(比如说除了AlarmDoor,还有AlarmChair、AlaramDesk、AlarmBike什么的),同时又具有Door的功能,那么上述的定义方式就要反过来了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: