【转载】浅谈 flash 中的设计模式：模版

文章来之：http://blog.zol.com.cn/822/article_821479.html

我们开发过程中肯定会希望这次做的东西下次还能用，于是我们提出了面向对象的开发方法，就是把开发过程当中的东西对象化、抽象化、功能化，这样以后就再用也很容易。对于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~~");
    }
  }
}

如此，我们便可以保证公有逻辑统一（改了父类，子类都会得到更改），而子类又保持着相对自由，独立的特性。这便是模板方法。