您的位置:首页 > 运维架构 > 网站架构

软件架构-接口的使用

2015-04-28 12:45 232 查看

有句话说:“面向接口编程”,这话没错。遗憾的是很多人将这句话曲解了,以为“面向接口编程”就是尽量使用接口,处处使用接口,结果造成接口滥用。
“过犹不及”,一种事物都是存在两个关节点,关节点之间就是度,任何事物,都要把握一个度的问题。“面向接口编程”,其实说的也是一个度的问题,为了解耦,达到更好的稳定性。同样,“解耦”,也是一种思路,也存在的度的问题,不能说任何东西都要解耦,处处解耦。如果不把握好这个度,你做的是个整体系统还是满地零件?
理解概念,不妨如前所述,从字面意思上着手,“接口”,两个汉字“接”和“口”,接,承接,转接,连接的意思,口,门户,开放窗口;接口就是提供连接的开放窗口。既然是接口是提供连接的开放窗口,那么,它必然要对接多个情况,存在统一接入标准,它的功能必然就是“方便插拔”,“应对变化”。
理解概念,将其放到真实生活中对比,是个不错的想法,接口,我们可以直观的类比电源插座,它是电网连接用电器的接口,它的特点就是方便连接与断开,凡是符合标准的插头都可以接入,可以随意更换用电器,当用电器故障的时候,不至于影响整个电网,实现电网和用电器的解耦,当用电器故障的时候,你只需拔下插头。
如果使用接口,我们可以从现实的简单插座的例子得到启发,接口就是为了应对变化和解耦的,对于没有变化或者解耦必要的地方,完全没有必要使用接口。“开闭原则”,除了“开”,还有另外一个方面,那就是“闭”,过分强调了“开”,而忽略了“闭”,是不符合设计原则的。“对变化开放,对稳定封闭”,“开放”和“封闭”同样重要。
我们不能处处做接口,处处开放。比如,现实中的一个例子,就汽车而言,我们是否有必要所有的地方都做成可插拔的?完全没有必要,对于发动机来说,它就是个紧耦合的东西,任何对发动的机的解耦都可能影响发送机的效能和安全性,也或者根本不能实现发动的目的。同样重要的是,没有必要松耦合,你硬要把发动机做成每个零件可插拔的,不仅达不到最初的设计目的,还会因此耗费大量的人力物力财力。汽车的各个部分,有松耦合,有紧耦合,发动机本身相对来说,紧耦合,但是轮胎,传动器,电路,刹车系统等等,他们之间则是松耦合,相互不会因为故障相互影响。一辆汽车,合理的用了松耦合,紧耦合,才是一辆成功的汽车。同样,一个好的软件,要合理的使用松耦合,紧耦合。我们说linux操作系统的代码是“艺术的代码,代码的艺术”,但是linux操作系统的代码是处处紧耦合。
使用接口,是有代价的。一种事物,都具有两面性,接口在方便插拔的同时,也存在着为了实现这个特性所需要付出的代价。在虚拟机实现中,类实例调用和接口调用存在着本质的不同,类的调用,在查找方法表的时候,只需要根据方法表指针偏移量就可以直接找到方法,进行调用;但是接口则不是,由于实现接口的类千差万别,也存在一个类实现多个接口的情况,那么每个类的接口方法的位置变得不固定,虚拟机执行的时候,无法直接根据偏移量确定方法的位置,它必须全表扫描方法表,进而确定方法的位置。所以,接口的调用比类实例的掉用慢的多。
权衡轻重,在可能出现变化的地方果断使用接口,在稳定的地方避免使用接口;坚持合理的“开闭”,开和闭同样重要。接口虽然方便,但是也要在需要的地方使用,而不是随便的使用。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
相关文章推荐