Java编程思想-第9章 接口(要点)

　　接口和内部类为我们提供了一种将接口与实现分离的更加结构化的方法。

　　这种机制在编程语言中并不通用。例如,C++对这些概念只有间接的支持。在Java中存在语 言关键字这个事实表明人们认为这些思想是很重要的,以至于要提供对它们的直接支持 首先,我们将学习抽象类,它是普通的类与接口之间的一种中庸之道。尽管在构建具有某 些未实现方法的类时,你的第一想法可能是创建接口,但是抽象类仍旧是用于此目的的一种重 要而必须的工具。因为你不可能总是使用纯接口。

9.1 抽象类和抽象方法

9.2 接口

　　 interface关键字使抽象的概念更向前迈进了一步。 abstract关键字允许人们在类中创建一个 或多个没有任何定义的方法——提供了接口部分,但是没有提供任何相应的具体实现,这些实 现是由此类的继承者创建的。 interface这个关键字产生一个完全抽象的类,它根本就没有提供 任何具体实现。它允许创建者确定方法名、参数列表和返回类型,但是没有任何方法体。接口 只提供了形式,而未提供任何具体实现。

9.3 完全解耦

　　 只要一个方法操作的是类而非接口,那么你就只能使用这个类及其子类。如果你想要将这 个方法应用于不在此继承结构中的某个类,那么你就会触霉头了。接口可以在很大程度上放宽 这种限制,因此,它使得我们可以编写可复用性更好的代码。

9.4 Java中的多重继承

　　 接口不仅仅只是一种更纯粹形式的抽象类,它的目标比这要高。因为接口是根本没有任何 具体实现的——也就是说,没有任何与接口相关的存储;因此,也就无法阻止多个接口的组合。 这一点是很有价值的,因为你有时需要去表示“一个x是一个a和一个b以及一个c”。在C++中 组合多个类的接口的行为被称作多重继承。它可能会使你背负很沉重的包袱,因为每个类都有 一个具体实现。在Java中,你可以执行相同的行为,但是只有一个类可以有具体实现;因此, 通过组合多个接口,C+中的问题是不会在Java中发生的。

9.5 通过继承来扩展接口

9.5.1 组合接口时的名字冲突

9.6 适配接口

　　 接口最吸引人的原因之一就是允许同一个接口具有多个不同的具体实现。在简单的情况中, 它的体现形式通常是一个接受接口类型的方法,而该接口的实现和向该方法传递的对象则取决 于方法的使用者。 因此,接口的一种常见用法就是前面提到的策略设计模式,此时你编写一个执行某些操作 的方法,而该方法将接受一个同样是你指定的接口。你主要就是要声明:“你可以用任何你想要 的对象来调用我的方法,只要你的对象遵循我的接口。”这使得你的方法更加灵活、通用,并更 具可复用性。

9.7 接口中的域

　　 因为你放入接口中的任何域都自动是 static和fnal的,所以接口就成为了一种很便捷的用来 创建常量组的工具。在 Java Se5之前,这是产生与C或C++中的enum(枚举类型)具有相同效果 的类型的唯一途径。

9.7.1 初始化接口中的域

9.8 嵌套接口

9.9 接口与工厂

9.10 总结

　　 “确定接口是理想选择,因而应该总是选择接口而不是具体的类。”这其实是一种引诱。当 然,对于创建类,几乎在任何时刻,都可以替代为创建一个接口和一个工厂。 许多人都掉进了这种诱惑的陷阱,只要有可能就去创建接口和工厂。这种逻辑看起来好像 是因为需要使用不同的具体实现,因此总是应该添加这种抽象性。这实际上已经变成了一种草 率的设计优化 。

　　任何抽象性都应该是应真正的需求而产生的。当必需时,你应该重构接口而不是到处添加 额外级别的间接性,并由此带来的额外的复杂性。这种额外的复杂性非常显著,如果你让某人 去处理这种复杂性,只是因为你意识到由于以防万一而添加了新接口,而没有其他更有说服力 的原因,那么好吧,如果我碰上了这种事,那么就会质疑此人所作的所有设计了。

　　恰当的原则应该是优先选择类而不是接口。从类开始,如果接口的必需性变得非常明确 那么就进行重构。接口是一种重要的工具,但是它们容易被滥用。