框架中的抽象类及接口应用

首先感谢http://blog.csdn.net/u011240877/article/details/78420277这篇大神给的启发

建议先去大神博客下了解抽象类及接口的原理，应用。

作为一个java小白，早先我对于接口和抽象类的理解，大概就是面试之前打开百度知道，然后粗略记下的也就是，单继承多实现，抽象类可以有非抽象方法，接口只有抽象的，抽象类可以用public和protected，接口只有public，这种因为不理解背着都费劲而且还没什么深度和技术层次的东西。大神的博客对此解释的十分全面。

其中，我认为最核心的，是设计上的，抽象类是一种由下及上的设计，它是你写了好多个类，然后发现，明明有很多个方法都是一样的，还重复写了好几个，既浪费资源，又不便于修改，所以把它们归在一起，形成一个父类，每一个子类再去继承父类，就可以get√这个方法，简单轻便易于维护。毕竟工作和学习是不一样的，在学校你写完的就是写完的没有然后了，工作中三天两头的改着需求，只改一处和改一大堆最后可能还漏几个类因为不常用没想起来没改，自然是只改一个要容易的多。接口是由上而下的设计，在干活之前，就定下来，它是有什么功能的，需要实现什么方法，这些个方法都需要什么参数返回什么类型实现什么功能。感觉起来，举个栗子，抽象类是我们几个狐朋狗友是怎么凑一堆的，发现我们的共同爱好，你没有这个爱好，不好意思你不是我们这个圈子的，你自己去一边玩；接口是大领导，领导说什么就是什么，领导让可什么标准怎么干，就得怎么干。

而且，一个类中，除了方法，还有属性和构造器，如果属性相同，比如这几个类都有个String name的属性，那也完全可以一起送到父类中，这样新写的类要有这个属性，直接继承就可以拥有这个属性（请注意不要在父类中把这个属性定义成private的）,节约资源。而接口是及其抽象的，属性其实并不算是个多么抽象的东西，所以尽量还是不要定义在接口中。构造器也是，无参的不必说，如果有好几个类的有参构造器是用的同样几个参数，那也完全可以放在父类中，这样继承父类的子类就直接拥有了这个有参构造器，不需要接连在几个类中都写上同样的构造方法，尤其是命名还不一样。接口显然，是没有构造器的。

实际应用中，个人倾向于接口，因为多实现嘛，如果某一天领导说，我觉得这里可以新加一个功能，你改改吧，你看了眼所有的实现都是由一个抽象类定下来的，然后你在抽象父类中新增了这个方法，第二天领导又说，不行不行，其中有几个模块我不要那个新增的功能。所以用接口就比较容易实现，先按照领导需求把接口定义好，谁要用这个功能，就实现这个接口，哪天说不要这个功能了，再取消实现就可以了。这种感觉起来形容就是抽象类是树的主干，轻易不要动，伤筋动骨的万一出点什么幺蛾子挺麻烦的，接口是枝干，想要随时可以添加，不要了也随时可以砍掉。

由于我们那个老项目中Controller或者说Action没有基类，我只能做个个人猜测，我认为BaseController如果存在，应该是个抽象类，因为没有人可以说这控制器是干什么的，都是干着干着发现，几乎所有的控制器都会有列表展示，这样就抽出来一个基类，这个基类当然也是可以没有的，并不耽误干活，但是可能我对列表查询命名叫/getList，别人叫/getPage，还有人叫/toList。。。。万一给所有列表页做修改，想找到哪个页的哪个方法，那真是，呵呵。而且编程大家也都知道，不是所有人都写注释的，我就觉得我叫getList简单明了易懂搁谁看都是列表页，那更是[手动再见].jpg。而且对于刚入职的可能分页还研究不明白的时候，找一个列表页研究，真的是挺费劲的。

项目的下一个层次是Service。这个毫无疑问是接口。因为必然要实现的CRUD是肯定的。剩下其他方法就各有各的谁也碍不着谁了，Service层现在基本都是Service接口和ServiceImpl的实现类。用接口做规范，不仅是强迫症看着舒服，过几个月忘了之前干过啥的时候改起来还是一样的迅速。

然后是Mapper或者DAO层。mybatis中mapper是接口毫无疑问，因为实现方法都在xml中，通过id对应方法的实现。其他的连库我认为应该也是接口，因为基础CRUD还是必备的。

新手小白的对大神指点的感想，可能说的并不准确，欢迎指点~

再次感谢大神写的辣么详细！