手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表Tag:接口

接口与抽象类【来自博客园】

什么是接口 (interface) ?

接口是方法的抽象,如果不同的类有同样的方法,那么就应该考虑使用接口。
(1)接口是一个行为的规范、协议。其实就是类和类之间的一种协定,一种约束
(2)C#不支持多继承,但是他把这个功能交给接口来实现。
(3)类与类之间的系统资源调用方式不一样,导致他们之间的通信很困难,而接口可以屏蔽掉它们之间的差异,能使他们顺利通信。

什么是抽象类(abstract class)?

1. 抽 象类仅提供一个类型的部分实现。抽象类可以有实例变量,以及一个或多个构造函数。抽象类可以同时有抽象方法和具体方法。一个抽象类不会有实例,这些构造函 数不能被客户端调用来创建实例。一个抽象类的构造函数可以被其子类调用,从而使一个抽象类的所有子类都可以有一些共同的实现,而不同的子类可以在此基础上 有其自己的实现。

2.  抽象类的用途1)  具体类不是用来继承的。 Scott Meyers曾指出,只要有可能,不要丛具体类继承。2)  假设有2个具体类,类A和类B,类B是类A 的子类,那么一个最简单的修改方案是应当建立一个抽象类(或java接口)C,然后让类A和类B成为抽象类C的子类。3)  抽象类应当拥有尽可能多的共同代码。以提高代码的复用率。4)  抽象类应当拥有尽可能少的数据。

 3.  基于抽象类的模式和原则1)  针对抽象编程,不要针对具体编程。2)  尽量使用合成(Composition),而不要使用继承来达到复用的目的。3)  使用摸板方法模式

4.  什么时候应当使用继承复用1)  子类是超类的一个特殊种类,而不是超类的一个角色,也就是要区分”is – a” 和“has-a”两种关系。2)  永远不会出现需要将子类换成另一个子类的情况。如果设计师不是很肯定一个类回不会在将来变成另一个类的子类的话,就不应当把这个类设计成这个超类的子类。 3)  子类具有扩展超类的责任,而不是具有置换掉(Override)或注销掉(Nullify)超类的责任。4)  只有在分类学上有意义时,才可以使用继承,不要丛工具类继承。

抽象方法是必须实现的方法。且只能在抽象类中。

接口与抽象类

一个类可以继承多个接口。。。
一个类只能继承一个抽象类。。。

抽象方法是必须实现的方法。就象动物都要呼吸。但是鱼用鳃呼吸,猪用肺呼吸。
动物类要有呼吸方法。怎么呼吸就是子类的事了。

现在有很多讨论和建议提倡用interface代替abstract类,两者从理论上可以做一般性的混用,但是在实际应用中,他们还是有一定区别的。抽象类一般作为公共的父类为子类的扩展提供基础,这里的扩展包括了属性上和行为上的。而接口一般来说不考虑属性,只考虑方法,使得子类可以自由的填补或者扩展接口所定义的方法,就像JAVA王子所说的事件中的适配器就是一个很好的应用。
用一个简单的例子,比如说一个教师,我们把它作为一个抽象类,有自己的属性,比如说年龄,教育程度,教师编号等等,而教师也是分很多种类的,我们就可以继承教师类而扩展特有的种类属性,而普遍属性已经直接继承了下来。
而接口呢~还是拿教师做例子,教师的行为很多,除了和普通人相同的以外,还有职业相关的行为,比如改考卷,讲课等等,我们把这些行为定义成无body的方 法,作为一个集合,它是一个interface。而教师张三李四的各自行为特点又有不同,那么他们就可以扩展自己的行为body。从这点意义上来说,interface偏重于行为
总之,在许多情况下,接口确实可以代替抽象类,如果你不需要刻意表达属性上的继承的话。

原文:http://www.cnblogs.com/cyc09156/archive/2009/01/09/1372330.html

Tags: 接口, 抽象, interface, abstract

为什么要做接口测试

最近一直被接口的事所烦恼,接口,测试,测试,接口。为什么要做,要做的目的是什么?

突然看到淘宝的QA上有这篇文章,立刻转摘,希望也能给其他想做接口或者正在做接口的朋友提供点帮助吧。

原文:http://rdc.taobao.com/blog/qa/?p=307
  1. 先给不了解接口测试的同学给个接口测试的定义:接口测试的目的是为了测试接口,尤其是那些与系统相关联的外部接口,测试的重点是要检查数据的交换,传递和控制管理过程,还包括处理的次数。(雪樱mm给出的非常好的定义,我盗用一下。)  
  2.   
  3. 本文主题是想谈谈为什么要做接口测试。曾经我们功能测试、性能测试、GUI自动化回归测试已经能够cover我们的测试需求,能够保证我们的网站质量。而随着产品功能越来越多,系统架构越来越复杂,新人越来越多,一些预想不到的缺陷突兀的出现在我们面前,我们怎么办?我们必须寻找一种更有效的测试方法来适应当前的变化,来持续保证我们的网站质量。因此接口的测试就是为了满足这个朴素的愿望。  
  4.   
  5. 从项目来说,由于产品的复杂度加大,系统的复杂度也加大,很多TestCase靠之前的GUI测试已经无法覆盖,那么必须深入代码,对代码进行更有力的破坏才能让系统更稳定。它不是站在系统角度的单元测试,而是与大多数功能测试一样是站在用户需求角度的接口测试。  
  6.   
  7. 从回归来说,也是有很朴素的需求存在:系统A改了一个接口,相关联系统B的开发人员并不知道(当然系统A的开发人员也不知道他会影响到B),导致A发布后,B出错,B的用户开始抱怨.此时如果有那么一套单元测试or接口测试在持续集成运行的话,当B测试出错,B的开发一下就能发现,也就能立即改掉。  
  8.   
  9. 因此接口测试不是仅仅为了接口的测试。只有它能够帮助我们做更多更好的测试,解决我们测试业务中的困难,保证我们当前GUI测试无法保证的质量,才是我们真正的目的。  

——END——

颇为感慨

Tags: 测试, 接口, 自动化