小弟刚工作两年文中所说都是通过自己工作中或做练习总结的经验,当然肯定不是那么准确,有不对之处望和谐指出,因为这个感觉完全是理论所以没有贴一段代码,有兴趣的就看看吧。
项目开发中绝对会碰到
接口,但是为什么要使用接口成了绝大多数java
程序员的疑问,为什么一定要写个没有实现任何功能的只有几个方名的类,可能也有一些人明白接口就是好,但好在哪里很难解释出来,我当初也是这样想的,但是当我一瞬间觉悟后
发现这种想法很幼稚。OOP的四大基本特征 多态 继承 封装 抽象 全与接口有关,可以说不懂接口的人完全不懂OOP是什么,更不用说能做出好项目,所以对接口的
理解很重要。讲接口之前再讲一样东西,它与接口是密不可分的,这两者必须要一起讲才行,那就是依赖注入(控制反转)。
spring的核心思想之一,又有
人有疑惑了,这东西很麻烦,还要在配置文件中配来配去,直接new一个不是挺好用的吗,多省事啊。
1依赖注入从编程方面讲提高了效率,在系统启动时容器将除去业务逻辑(因为业务不是时时刻刻都会用到的)以外的一大部分方法加载到
内存中,一个请求过来时你要哪个方法我从内存中给你哪个方法,而new的时候是需要在内存中分出一点空间来放你new出来的东西,一百个请求new一百次,一亿个请求new一亿次。
2依赖注入从
设计模式上来讲提高了解耦性,重用性,与传统的new,一个是给一个是拿(用控制反转来理解这句话)。举例:你要一辆车,自己造一辆(new)。依赖注入像汽车中心(容器)买或者租一辆.自己造要花时间造,汽车场给钱立马给你。如果你就开一次,自己造完了用了一次丢那里浪费了,汽车场租一辆,用完就还回去,别人还能用。可能你又会想,自己造的别人也还能用啊,但那只限于知道你有辆车的人,但只要是人都知道汽车场有汽车。
讲完依赖注入就可以讲接口了。接口的基本特征就不多说了,下面来讲接口到底好在哪
一.目录
开发一个项目中,总是需要互相调用一些功能的,比如业务组开发人员需要技术组提供一些实用的方法,那么就出现了两种情况。
1.不使用接口,直接写。
当
你需要去看看这个类有什么你需要的方法时,你看到的是一大堆的代码,悲剧了,几千行代码,有的方法几百行有的方法一两行,哪个是我要的方法呢,一个个找吧,更悲剧者碰上
编码习惯不好的,不管是外部方法还是内部封装一下的小方法的修饰名全都用Public,找晕你。
2使用接口
接口没有任何的实现,只有方法名,一排一排很有规则的看下去,我不需要去看他的
实现过程,我只需要知道这我想要的达到的目的通过哪个方法能实现,至于他的过程本来就不需要我来考虑。
举例:你买了本
hibernate编程思想,你想要知道怎么配置hibernate的参数。翻开一看,蛋疼,没有目录,你就一页一页翻吧,翻的同时还得看清楚点,别翻过头了。
二.变更
开发项目中,不免会有一些大的变更,甚至于
上线之后都有可能,那么一些影响
全局的变更就出现了。比如数据库本来用的是MySql,变态的需求突然说要换成oracle。
1 没有使用接口开发
写一个新的类,把所有调用的全改掉,因为类型都不对了。
2 使用接口的类
只需要在写一个SQL接口的实现类,在配置文件中修改一下注入的路径,搞定。
有人又会说直接改那个内的方法不就可以了,那我需求再变态一下,白天用MySql晚上用oracle,那是否你所有操作数据库之前都要if(白天)else if(晚上)?,而接口只需要容器支持将注入的实现类换一个就行了,因为实现类必须实现接口的所有抽象方法,所以在编译时是能通过的。
举例:一个医院有一个口腔部门,口腔部门里有一位医生叫王医生,通过写死的看法我如果要去看病就是找这个王医生,一天王医生不干了,来了一个刘医生,完了我只能看王医生的,这可能吗
?通过接口来看医院是接口他能治病,口腔部门是医院的子类,明确到了是治疗口腔的,医生是实现类,他能治口腔病,至于这个医生叫什么,关我屁事,我只要知道你有治病这个方法就行了。
三.
扩展性
最近工作太轻松,闲来
无聊做了个练习小项目,这个项目除了必要的DOM4J和JDBC没用一个jar包,前言说完了,说说我的做法。项目启动时先加载自己做的容器,然后加载DB、Log等接口、最后加载service、action,刚开始我在加载容器后就直接按顺序把DB配置文件加载好生成一个DB
Service丢到数据总线中,然后加载LOG同样的做法。考虑了很久发现这种做法有点问题,后来改成这样了,容器无非就是管理接口类的东西,我就又写了个抽象类(因为抽象类可以有成员变量)一个抽象方法initService 两个成员变量 HashMap serviceMap
HashMap serviceDataMap 一个存service 一个存它可能会附带的一些数据,我现在只需要写实现类 在initService 方法中加载
XML 将该Service初始化好 丢到serviceMap中就哦了,这样做的好处就是,无论我以后有多少插件配置文件配一个实现类,写一个实现类,方法中加载一些东西,丢到父类的serviceMap中,以后所有的类注入都能注入该service。
四.结构化
一个项目的好坏就要看他的结构是否清晰,java规定了类只能单一继承,是为了避免错综复杂的关系,在很多文章中都提到过类的继承是项目中的一颗地雷,而接口没有实现过程,只有表明是干什么的,所以就算多继承(接口可以继承多个接口),结构还是很清晰的。
自我总结出就这四个优点很明显,看别人的文章说的
最多的还有一个好处开发中使用,我觉得很恶心,实现屁没写方法一大堆,写完一大堆的方法后,去写实现时突然发现又要加个新方法才行或者写好的那个方法又没啥用,要删掉,最后搞的你心思无限宽广,有时候开发过程想太多太远是没好处的,可能写的过程中又会出现很多其他的想法,因为我们是人,不是CPU,运行的不是那么准确,当然几乎每个
架构师技术都很牛X,估计也是有人能做到这一点的,但是做不到的还是慢慢来,都写好了再弄个接口或抽象类。
最后总结一点 接口就是你需要什么就调什么 完完全全的封装 不用考虑你的实现过程 连类名都可以忽略 你只要告诉容器 我需要的是哪种类型的接口就行了
?