再理解 as3.0接口

As3.0 接口的理解与运用  

1.把接口当作来理解,你容易接受她。 我们看她的标准结构: 

package 包路径{         

public interface 接口名称{               

function 方法名(参数:参数类型):返回类型;               

static function 方法名(参数:参数类型):返回类型;              

function get 方法名():返回类型;               

function set 方法名(参数:参数类型):void;       } }  

特记:方法没有大括号{},就是只是声明方法,而没有实体。有名无实!   

2. 接口是为类准备的组件,没有类,接口什么用处也没有。 类是实现接口方法的唯一途径。  

3. 类使用接口时,当作继承来理解,尽管与类的继承不一样。 在继承时,必须”“完全”“覆盖接口中的方法属性。让接口的方法有实体,名符其实了,才能顺理成章地干活! 

4. 接口可以被类多继承,反言之:一个类可以实现多个接口,这正是接口的优点。老祖宗多,家产兴旺、财源滚滚! 

接口一: packageLir{     

publicinterface IALL{     

function clone1():String;  

}  

}  

接口二: packageLir{     

publicinterface IDLL{     

function clone1():String;  

}  

}  

使用多接口的类: packageLir{     

publicclass AD implements IALL,IDLL{     

public function clone1():String {     

return "clone1";    

}  

public function clone2():String {      

return "clone2";    

}  

}  }

应用:  

package com{  

importflash.display.Sprite;  

public class testclass extends Sprite { 

public function testclass():void  { 

var ftt1:IALL = new AD();//看这行 

var ftt2:ICLL = new AD();//再看这行 

trace(ftt1.clone1()); trace(ftt2.clone2());   

}  } } 

 这是个简单的应用,所以还没有显现出优势来,你的心理也许认为:还不如用类简单呢!如果在大型游戏制作中,程序员的体验可就不同了。  

 5.接口是自定义数据类型。  

一个类实现了一个接口的话,除了它自身的类型外,还多一个身份:接口定义的类型。这样一来,好多本不相关的类就可能通过一个接口相关起来。就像许多孤儿,被一个伟大的父亲收养了,孤儿有了共同的父亲,就可以交流交往、相亲相爱了。 

例子:  

所有继承IAll接口的子类myTxtmyMcmyShape„„都可以这样声明: varmytxt:IAll=new myTxt() 

varmymc:IAll=new myMc()  

varmyshape:IAll=new myShape() „„  

 当我们要从舞台上移除所有的属于IAll的可视化元件时,

只需要 If(实例 is IAll)this.removeChild(实例)} 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
一个就是使用继承。比方说,你可以先创建一个颜色处理器的。 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多个的时候,或者再细分至省和洲的时候,这一做法的优势就更为明显了。 总结起来,可以得知,在继承结构不能仅用树状去表示,如上面的具有交叉继承结构的时候,就建议用接口了。但是,如果是简单的树状结构,我觉得还是用继承好些,毕竟这样的做法也有维护上的优势。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值