我们开发过程中肯定会希望这次做的东西下次还能用,于是我们提出了面向对象的开发方法,就是把开发过程当中的东西对象化、抽象化、功能化,这样以后就再用也很容易。对于flash开发而言,macromedia(现在是adobe)提供了一种更简单的方法:组件。
于是做flash开发的时候要随时惦记着这件事情,时刻想着能不能把现在做的这个东西转换成组件,以及转换成组件只能怎么保证灵活性和通用性。
比如这次做图片上传的插件,里面需要3个标签来切换不同的功能,那么很容易就想到tabBar这个组件,但是flex3有而flash没有,去网上找了会儿没找到(当时居然忘记yahoo flash开发社区了……),想着反正不难,就自己写了。
这个时候就要考虑了,怎样写,这个标签切换才能更加通用呢?首先,不同的地方标签的外观肯定是不同的,功能倒绝对的大同小异,那么就需要外观比较自由的按钮。flash as3开发里面,基本上是将每个外观封装成一个元件,然后绑定到一个类上,使用的时候,实例化这个类,就可以使用由flash ide创建的外观,和as定义的功能了。换言之,在具体应用的时候,我们只需要写一个类,让他具有和组件中标签按钮具有一样的功能,然后替换掉组件中的标签按钮,就可以了。
习惯面向对象编程思维的同学第一反应一定是接口(我就是~),确实,在这种典型的多态特征下,定义接口并且实现接口是一种解决方案。但是这里有一个问题就是这些按钮还有一些公共的业务逻辑,我们当然希望在基类里面包含起来,而接口是不能实现方法的。于是我转而使用设计模式中的“模板方法”。
模板方法是这样的,定义一个不能实例化的抽象类,里面实现了一些公共方法,需要子类重写的方法直接抛出一个异常。使用的时候,用一个类来继承它,并且使用override关键字把需要重写的方法重写一遍,将特殊的方法在特殊类中实现。
简单的代码表述是这样子的:
package{
import flash.display.Sprite;
public class AbstractButton extends Sprite{
public final function init():void{
//这个方法就是实现公用逻辑的方法,使用final关键字来避免被子类改写
}
public function abstractMethod():void{
//抽象方法,只需要抛出一个异常
throw new Error("Abstract Method!");
}
}
}
package{
public class myButton extends AbstractButton{
public override function abstractMethod():void{
//在这里进行复写,以便实现当下的特有逻辑
trace("override abstract method~~");
}
}
}
如此,我们便可以保证公有逻辑统一(改了父类,子类都会得到更改),而子类又保持着相对自由,独立的特性。这便是模板方法。
于是做flash开发的时候要随时惦记着这件事情,时刻想着能不能把现在做的这个东西转换成组件,以及转换成组件只能怎么保证灵活性和通用性。
比如这次做图片上传的插件,里面需要3个标签来切换不同的功能,那么很容易就想到tabBar这个组件,但是flex3有而flash没有,去网上找了会儿没找到(当时居然忘记yahoo flash开发社区了……),想着反正不难,就自己写了。
这个时候就要考虑了,怎样写,这个标签切换才能更加通用呢?首先,不同的地方标签的外观肯定是不同的,功能倒绝对的大同小异,那么就需要外观比较自由的按钮。flash as3开发里面,基本上是将每个外观封装成一个元件,然后绑定到一个类上,使用的时候,实例化这个类,就可以使用由flash ide创建的外观,和as定义的功能了。换言之,在具体应用的时候,我们只需要写一个类,让他具有和组件中标签按钮具有一样的功能,然后替换掉组件中的标签按钮,就可以了。
习惯面向对象编程思维的同学第一反应一定是接口(我就是~),确实,在这种典型的多态特征下,定义接口并且实现接口是一种解决方案。但是这里有一个问题就是这些按钮还有一些公共的业务逻辑,我们当然希望在基类里面包含起来,而接口是不能实现方法的。于是我转而使用设计模式中的“模板方法”。
模板方法是这样的,定义一个不能实例化的抽象类,里面实现了一些公共方法,需要子类重写的方法直接抛出一个异常。使用的时候,用一个类来继承它,并且使用override关键字把需要重写的方法重写一遍,将特殊的方法在特殊类中实现。
简单的代码表述是这样子的:
package{
import flash.display.Sprite;
public class AbstractButton extends Sprite{
public final function init():void{
//这个方法就是实现公用逻辑的方法,使用final关键字来避免被子类改写
}
public function abstractMethod():void{
//抽象方法,只需要抛出一个异常
throw new Error("Abstract Method!");
}
}
}
package{
public class myButton extends AbstractButton{
public override function abstractMethod():void{
//在这里进行复写,以便实现当下的特有逻辑
trace("override abstract method~~");
}
}
}
如此,我们便可以保证公有逻辑统一(改了父类,子类都会得到更改),而子类又保持着相对自由,独立的特性。这便是模板方法。