文件名称：as3 接口类的用法和好处
文件大小：40KB
文件格式：DOC
更新时间：2015-02-05 04:52:22
AS3接口
一个就是使用继承。比方说，你可以先创建一个颜色处理器的类。 package{ public class colorProcessor{ public function setFillColor(color:uint):void{ } } } 然后，形状和文本就可以继承colorProcessor类了。 package{ public class shapeClass extends colorProcessor{ override public function setFillColor(color:uint):void{ //.... } //由于还可以设置线条，你可以在这里新加一个方法 public function setLineColor(color:uint):void{ //.... } } } package{ public class textClass extends colorProcessor{ override public function setFillColor(color:uint):void{ //.... } } } 因为对文本和对形状的填充颜色设置可能会采用不同的实现方法，比方说，中国人吃饭和外国人吃饭都是吃饭，但是中国人可能用筷子，外国人则用刀叉。所以，在colorProcessor里，setFillColor就没有包含方法的实现了，给被继承的类自我扩充。 第二种方法，使用接口。把colorProcessor写成接口。 package{ public interface IColorProcessor{ functon setFillColor(color:uint):void } } 然后形状和文本类则改成 package{ public class shapeClass implements IColorProcessor{ public function setFillColor(color:uint):void{ //.... } //由于还可以设置线条，你可以在这里新加一个方法 public function setLineColor(color:uint):void{ //.... } } } package{ public class textClass implements IColorProcessor{ public function setFillColor(color:uint):void{ //.... } } } 这 么看起来，colorProcessor类和IColorProcessor接口没有太大区别。这两个都声明了方法，也没有包含方法的实现。使用继承父类 的，则通过覆盖方法来实现被继承类的方法，而实现接口的则在接口实现的类里写出了方法的实现。像colorProcessor里这种只声明方法，里面实际 上没有方法实现的类，实际上是运用了抽象类的思想。不过，在AS3里尚不可自定义抽象类，所以，所谓的抽象类也只是有形无实。真正的抽象类跟接口一样，不 能实例化，而且，继承者必须覆盖抽象类的所有方法才可以实例化（所以这点跟接口也很相似）。AS3有内置的抽象类如 DisplayObjectContainer，大家可以尝试去用来测试实例化，继承的可行性。 说到这里，其实还是没有说明接口存在的必要性。显 然，上面的形状和文本类，即使没有“抽象类”和接口，两个类照样可以正常运行。但是，假若现在加入了MC，MC不具备设置颜色的属性，那么，在Flash 的IDE下，你使用颜料桶工具将无法对MC进行颜色填充，如果你要开发一个Flash的IDE，那么，你就将要对你选中的对象进行判断，它是文本，形状， 还是MC。 在AS3里，与对象类型有关的运算主要有以下几种： getQualifiedClassName getQualifiedSuperclassName is instanceof(还是推荐用is代替) as getQuailiedClassName可以获取该对象的类型，返回的是类名。假若my_txt是文本，my_shape是形状，那么，就有 getQualifiedClassName(my_txt)将返回textClass getQualifiedClassName(my_shape)将返回shapeClass 那么，在仅有这三种对象存在，并且该三种对象没有扩展的时候，判断被选定对象可以用if或者switch，如 switch(getQuailiedClassName(currentObj)){ case "shapeClass": case "textClass": currentObj.setFillColor(newColor); break; case "mcClass": //do nothing break; } 但是，文本还可以有动态文本，静态文本，输入文本等子类，形状可能有矩形，圆形等子类，那么，你目前还是有办法可以处理这个问题： switch(getQuailiedClassName(currentObj)){ case "shapeClass": case "textClass": case "triangleClass": case "rectangleClass": case "dynamicTextClass": case "staticTextClass": case "inputTextClass": currentObj.setFillColor(newColor); break; case "mcClass": //do nothing break; } 多麻烦啊~而且当继承结构复杂的时候，都不知道该写多少句了。因此，getQualifiedSuperclassName就在这里起了点作用。可以检查其超类是否为shapeClass或者textClass。 但 是，这个函数只能检查到上一级的类名，若继承结构复杂，可能有的继承两至三级甚至更多，在不知道继承级别的情况下，用 getQualifiedSuperclassName想知道对象的继承关系链里是否存在textClass或者shapeClass，就只能通过遍历至 *类来检验了......不但麻烦，而且效率低。 is运算符诞生啦！这一运算符可以检验某对象是否为指定类的实例，只要指定类在继承关系链中，都返回true。另外也包括接口。也就是说，假设my_spr是一个Sprite类的实例，那么下面的三个表达式都输出true trace(my_spr is Sprite); trace(my_spr is DisplayObjectContainer); trace(my_spr is IEventDispatcher); 回到刚才说的那个选定对象的问题。假设舞台上现在既有MC，又有形状，也有文本。而且形状有圆形，矩形等子类的实例，文本有静态文本和动态文本。那么，当选定一个对象时，要确定该对象是否具有颜色填充的功能，就可以将上面的代码简化为： if((currentObj is textClass) or (currentObj is shapeClass)){ currentObj.setFillColor(newColor); }else if(currentObj is mcClass){ //do nothing } 代码得到了简化，可惜的是，其适应性还是相当有限，如果可以进行颜色填充的类也有很多，不止textClass和shapeClass的话，此段代码还是要重复写很多很长的“排比句”。 这时，接口起到了作用。因为textClass和shapeClass都是IColorProcessor的接口实现类，所以，按照is的运算规则，上面的代码就可以简化成 if((currentObj is IColorProcessor)){ currentObj.setFillColor(newColor); }else if(currentObj is mcClass){ //do nothing } 那么，只要具有填充颜色功能的类都实现IColorProcessor接口，就返回true，就可以进行颜色填充，而不需要再检查具体是什么类实现该接口了，也不用考虑继承关系，多方便。 既然如此，那么为什么不能用“抽象类”代替接口呢？如果textClass和shapeClass都继承colorProcessor类，然后检查currentObj is colorProcessor不也一样嘛？接口有何种特性是抽象类不具备的呢？ 至此，我终于没办法了，要翻Java的技术文章来看，了解下接口和抽象类的区别所在。 在我所看到的文章中，貌似都认为抽象类的优势比接口还大，不过却推荐使用接口，而不用抽象类。看到那些文章后面的地方，终于茅塞顿开啦~~ 在讲接口的优势之前，我先继续刚才的Flash IDE开发问题。 现在，假设你开发到Flash 8，要添加上滤镜功能，但是滤镜只可以加在文本和MC上，那么，你可以先定义一个“抽象类”： package{ public class filterProcessor{ public function setFilters(filt_arr:Array):void{ } } } 然后由mcClass来继承： package{ public class mcClass extends filterProcessor{ override public function setFilters(filt_arr:Array):void{ } } } 至于文本，同样地，可以用： package{ public class textClass extends filterProcessor{ override public function setFilters(filt_arr:Array):void{ } } } 文本这里就出问题了，这么写，之前文本继承的colorProcessor类就没有了。但是，在AS3里，你不能这么写： package{ public class textClass extends filterProcessor extends colorProcessor{ override public function setFilters(filt_arr:Array):void{ } } } 也不可以写成： package{ public class textClass extends filterProcessor,colorProceessor{ override public function setFilters(filt_arr:Array):void{ } } } 那 么，如果想同时继承这两个类，该怎么办呢？你不可以说先让colorProcessor和filterProcessor相互继承，假如颜色处理器继承了 滤镜处理器，那将意味着，形状也可以设置滤镜（这就错掉啦）。如果反过来，就会导致MC可以进行颜色填充（也不行啊）。 在这种情况下，接口的优势就体现出来啦。 原来，接口和抽象类相比，多出的一个优势在于（仅限Java和AS3），一个类可以实现多个接口，但是不能继承多个类。所以，如果在这里改用接口，就一切都好解决了。先定义两个接口： package{ public interface IColorProcessor{ function setFillColor(color:uint):void; } } package{ public interface IFilterProcessor{ function setFilters(filt_arr:Array):void; } } 然后，形状，文本和MC就分别用如下的方式实现接口： package{ public class shapeClass implements IColorProcessor{ public function setFillColor(color:uint):void{ } } } package{ public class textClass implements IColorProcessor,IFilterProcessor{ public function setFillColor(color:uint):void{ } } } package{ public class mcClass implements IFilterProcessor{ public function setFillColor(color:uint):void{ } } } 这样实现了接口以后，在舞台上假如形状，MC，文本都存在的话，你也不需要检查他们是什么类了，只要了解他们实现的接口就OK。 if(currentObj is IColorProcessor){ (currentObj as IColorProcessor).setFillColor(newColor); } if(currentObj is IFilterProcessor){ (currentObj as IFilterProcessor).setFilters(filt_arr); } 可 见，定义了接口，在处理多种类型的对象过程中会方便很多（可能有人会说，假若方法真的不存在，用try...catch不一样可以处理掉嘛.....，不 过......用这样的处理错误方法，在对象多的时候，运行起来的状况会怎样呢？）。从研究接口用处的过程中，我们发现，接口的产生其实是源于Java和 AS3对类多态（多继承）的限制。为了可以更好地对类的特性进行描述，判断处理，接口就显得相当有必要了。 _____________________________________ 讲到现在，我发现自己似乎还没有讲明白问题。但是这个时候我MS已经想到了一个更为实际的例子： 刚 讲了中国人和外国人都继承了人类，现在，假设要对中国人和外国人再一次进行分类，都按性别再分别对中国人和外国人进行分类。假如全部用类来做的话，就是先 有一个最*的人类，接着就是中国人类和外国人类，男人类和女人类，接着就是中国男人，中国女人，外国男人，外国女人。 前面说了，AS3和Java不能继承多个类（前面没看的也没关系，现在你知道就可以了）。所以，你的继承可以有两种策略，不过，*的人类是无可争议的了。 package{ public class person{ } } 然后，第一种策略，就是先把人类分成中国人和外国人： package{ public class Chinese extends person{ } } package{ public class Foreigner extends person{ } } 接着再把他们分别分成男和女的： package{ public class Chinese_man extends Chinese{ } } package{ public class Chinese_woman extends Chinese{ } } package{ public class Foreign_man extends Foreigner{ } } package{ public class Foreign_woman extends Foreigner{ } } 第二种策略，跟第一种策略相反。先按性别分，再按地区分： package{ public class man extends person{ } } package{ public class woman extends person{ } } 接下来的就是 package{ public class Chinese_man extends man{ } } package{ public class Chinese_woman extends woman{ } } package{ public class Foreign_man extends man{ } } package{ public class Foreign_woman extends woman{ } } 现在分好了，开始要让他们做两件事情： 1 让外国人在中国环游一周； 2 组织全体女性到联合国的妇联开会。 按 照第一种策略的话，让外国人在中国环游一周，就只需要让所有外国人类的实例都调用一个环游的方法就可以了。但是，若要完成第二个任务，就需要先对中国的女 性调用一个组织开会的方法，再对外国女性调用一个组织开会的方法。相反，第二种策略就让第一个任务完成得比较麻烦，第二个任务就相对方便。鱼和熊掌，两者 不可兼得。 但是，如果使用接口呢？情况就大大不同。 在定义了人的接口以后： package{ public interface IPerson{ } } 再定义四个接口：男人，女人，中国人，外国人： package{ public interface IMan extends IPerson{ } package{ public interface IWoman extends IPerson{ } package{ public interface IForeigner extends IPerson{ } package{ public interface IChinese extends IPerson{ } 接下来就定义中国男人，中国女人，外国男人，外国女人。这时可以用类了。 package{ public class Chinese_man implements IMan,IChinese{ } } package{ public class Chinese_woman implements IWoman,IChinese{ } } package{ public class Foreign_man implements IMan,IForeigner{ } } package{ public class Foreign_woman implements IWoan,IForeigner{ } } 同 样完成上面的两个任务，第一个，只需要调用实现接口IForeigner的类就OK了，同样地，第二个也只需要调用实现接口IWoman的类。当分区分 细，不再按中国人外国人分类，而要按照国籍来分成200多个类的时候，或者再细分至省和洲的时候，这一做法的优势就更为明显了。 总结起来，可以得知，在类的继承结构不能仅用树状去表示，如上面的具有交叉继承结构的时候，就建议用接口了。但是，如果是简单的树状结构，我觉得还是用类继承好些，毕竟这样的做法也有维护上的优势。