又一个臭大街的话题，所以本次依然尽量不走寻常路。
1. 接口
我们在学习接口和抽象类时，都会碰到一大堆示例代码，而这些示例代码基本都是使用生活中的实例进行类比时；这样虽然贴切了生活，但里面有个问题，例如你举例锤子，初学者除了领悟到它的敲钉子特性之外，还会在意它的型，但是软件开发里是不在意型的，我拿砖头去完成锤子的功能也是可以的，当然瑞士军刀也是可以的了。
这里依然讲解一个让本人顿悟的例子: 《编写高质量代码 — 改善Java程序的151个建议》 其中第294页的 ”建议147-让接口的职责保持单一“；对鄙人来说，绝对算得上一语点醒梦中人！
- 接口职责一定要单一，
- 实现类职责尽量单一。
其中的例子我就不在这里重复了，建议去阅读下。后期我会视情况再贴上一两个例子，现在手机编辑不好上代码。
还有就是《你必须知道的.NET》里将接口类比为”身份“， 不过本人更倾向于将它们类比为”标签”。典型例子就是Java里的标志性接口——作为一个没有声明任何内容的接口，其唯一的作用也就剩给实现者打标了。虽然某本经典书籍（原谅我又把名字给忘记了。）上谈到标志性接口是设计不当的产物，不过你不能否认的是它确实是一个非常好的补救措施。
另外在Spring或Tomcat源码里我们经常可以看到形如这样的代码
if (servlet instanceof CometProcessor){
// do something
}
- 这样我们可以通过判断传递进来的实例身上是否有这个标签，来决定某些行为。
- 像Spring, Tomcat这样优秀的，历经如此长时间的考验的优秀框架里，必然少不了这样的代码。
- 这是一种非常值得学习的技巧. 为了系统稳定考虑, 我们很少会直接通过修改现有代码的逻辑来达到扩展的目的,如果采用以上的方式,我们就可以在不动现有逻辑流程的前提下,将新的需求引发的变化导向到我们的扩展类中.
- 类似的还有《How Tomcat Works》在P431 里提到的 ContainerServlet
- Wrapper在加载其包裹的Servlet时, 会判断该Servlet实现类是否实现了
ContainerServlet接口, 若实现则将Wrapper自身通过ContainerServlet接口提供的方法注入到Servlet实例中. 这样该Servlet就能拿到整个容器的信息。 - 最小的修改达到目的。
- Wrapper在加载其包裹的Servlet时, 会判断该Servlet实现类是否实现了
2. 抽象类
关于抽象类，个人认为抽象类更偏重于代码复用！直接例子就是MyBatis里的BaseBuilder类了，其完全没有定义任何抽象方法。
如果抛开抽象类与接口的区别来避免凑字数之嫌，个人目前就没有什么其它个人见解了；如果以后有更深的感悟，我会回来继续完善这篇文章的。
3. 补充
- ”接口是设计的产物，而抽象类是重构的产物”。很有道理的言论，可惜不是我自己的总结。
- “方法的参数越抽象越好，而返回值越具体越好。”好吧，这一句我再次无法想起是在哪本买到的纸质书里看到的了，好像是《CLR via C#》吧。所以设计良好的方法，其方法参数一般都会是接口或抽象类，这样就保证了方法的稳定性和通用性。
