接口和抽象类

抽象类允许某些方法的实现，但是接口不允许(JDK 1.8 已经运行了)
现有类必须成为抽象类的子类，但是只能单继承，接口可以多继承

抽象类小优势

抽象类并非一无是处，它的改变就比接口要简易的多，实际使用时也是体验很好的一种设计方法，不过抽象类的使用也要有所衡量，只有在确实是属于一个类别的类时才好去使用抽象类，否则就违背了我们的编程原则

接口优点

现有类可以很容易被更新，以实现新的接口 只需要在接口中添加方法就可以了
接口是定义 mixin （混合类型）的理想选择 mixin：类除了实现它的“基本类型”之外，还可以实现 mixin 类型，表明它提供了可供选择的行为，例如 Comparable
接口允许我们构造非层次结构的类型框架
接口可以使得类的增强变得安全

例：假设我们有一个接口代表一个singer，另一个接口代表一个songweiter。

public interface Singer{
 AudioClip sing(Song s);
}
public interface Songwriter{
 Song compose(boolean hit);
}

在现实生活中，有些歌唱家本身也是作曲家。因为我们使用了接口而不是抽象类来定义这些类型，所以对于单个类而言，它同时实现Singer和Songwriter是允许的，实际上我们可以定义第三个接口，他同时扩展了Singer和Songwriter，并添加了一些适合于这种组合的新方法：

public interface SingerSongwriter extends Singer, Songwriter{
 AudioClip strum();
 void actSensitive();
}

你并不是总是需要这种灵活性，但是一旦你这样做了，接口可就成为了救世主，能帮助你解决大问题。

另外一种做法是编写一个臃肿的类层次，对于每一种要被支持的属性组合，都包含一个单独的类。如果在整个类型系统中有n个属性，那么必须支持2^n种可能的组合。这种现象被称为“组合爆炸”。类层次的臃肿也导致类也臃肿，这些类也包含许多方法，并且这些方法只是在参数的类型上有所不同而已，因为类层次中没有任何类型体现公共的行为特征。

骨架类

众所周知，java 8之前接口是不可以有方法体的，==这就是抽象类相对于接口的优势==，为了将抽象类和接口的优势整合起来，“骨架类”就诞生了，骨架类的做法是用一个抽象类来实现一个接口，在抽象类中为接口的某些方法提供实现。

骨架实现被称为AbstractInterface，这里的Interface是指所实现的接口的名字。例如，Collections Framework为每个重要的集合接口都提供了一个骨架实现，包括 AbstractCollection 、AbstractSet 、AbstractList 和 AbstractMap 。将他们称为 SkeletalCollection 、SkeletalSet 、SkeletalList 和 SkeletalMap 也是有道理的，但是现在Abstract的用法已经根深蒂固。

骨架类的实现的一般步骤是:

1.找出接口中的基本方法
2.在抽象类中声明为抽象方法
3.然后用这些基本方法来实现其他方法，所谓基本方法，就是通过将这些方法组合或是变换，可以实现其他的方法。

编写骨架实现类相对比较简单，只是有点单调乏味。

首先，必须认真研究接口，并确定哪些方法时最为基本的，其他方法则可以根据它们来实现。这些方法将成为骨架实现类中的抽象方法。
然后，必须为接口中的所有其他的方法提供具体实现。

骨架类的例子

假设有一个接口，它可以实现一组对象的求和：

public interface Summation<T> {
	// 实现两个对象的相加
	T towEleAdd(T obj01, T obj02);

	// 实现List求和
	T listEleSum(List<T> list);

	// 实现数组求和
	T arrayEleSum(T[] array);
}

实现他的“骨架”：

public abstract class AbstractSummation<T> implements Summation<T> {

	@Override
	public abstract T towEleAdd(T obj01, T obj02);

	@Override
	public T listEleSum(List<T> list) {
		T firstEle = null;
		for (T t : list) {


			if (firstEle == null) {
				firstEle = t;
				continue;
			}


			firstEle = towEleAdd(firstEle, t);
		}
		return firstEle;
	}


	@Override
	public T arrayEleSum(T[] array) {
		T firstEle = null;
		for (T t : array) {


			if (firstEle == null) {
				firstEle = t;
				continue;
			}


			firstEle = towEleAdd(firstEle, t);
		}
		return firstEle;
	}
}

继承这个骨架类就只用实现towEleAdd方法，就可以完成一组对象的求和工作了。骨架实现类时为了继承的目的而设计的。

骨架类的优势

骨架实现的美妙之处在于，它们为抽象类提供了实现上的帮助，但又不强加“抽象类被用作类型定义时”所特有的严格限制。 对于接口的大多数实现来讲，扩展骨架实现类是个很明显的选择，但不是必须的。如果预置的类无法扩展骨架实现类，这个类始终可以手工实现这个接口。此外，骨架实现类仍然能够有助于接口的实现。实现这个接口的类可以把对于接口方法的调用，转发到一个内部私有类的实例上，这个内部私有类扩展了骨架实现类。这种方法被称作模拟多态继承，它与第16条中讨论的包装类模式密切相关。这项技术具有多重继承的绝大多数有点，同时又避免了相应的缺陷。

参考文献

《Effective Java》 blog.csdn.net/dingjianmin…

在这里插入图片描述

本公众号分享自己从程序员小白到经历春招秋招斩获10几个offer的面试笔试经验，其中包括【Java】、【操作系统】、【计算机网络】、【设计模式】、【数据结构与算法】、【大厂面经】、【数据库】期待你加入！！！

《Effective Java》阅读笔记 18接口优于抽象类