AS3.0 currentTarget和target详解

currentTarget:

 

 官方解释:当前正在使用某个事件侦听器处理 Event 对象的对象。

 个人理解:添加事件侦听器的对象(继承EventDispatcher类或实现IEventDispatcher接口);

 举例:a1.addEventListener(...............); 这里的a1就是currentTarget。

 

 

target:

 

 官方解释:事件目标。

 个人理解:发出该事件的对象(继承EventDispatcher类或实现IEventDispatcher接口);

 举例:a1.dispatchEvent(new Event(........)); 这里的a1就是target。

   对于鼠标事件,鼠标点击的对象就是发出事件的对象,也就是target。

   对于键盘事件,stage.focus所指的对象就是发出事件的对象,也就是target。

 

-----------------------------------------------------注:以上个人理解部分难免有所疏忽,还请大家指正。

转载于:https://www.cnblogs.com/sdlwlxf/archive/2012/12/12/2815306.html

一个就是使用继承。比方说,你可以先创建一个颜色处理器的类。 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、付费专栏及课程。

余额充值