plasticular inscriptor » eclipse http://www.plasticstare.com/plains Thu, 02 Feb 2012 02:19:43 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Interfacing in Actionscript http://www.plasticstare.com/plains/2006/08/25/interfacing-in-actionscript/ http://www.plasticstare.com/plains/2006/08/25/interfacing-in-actionscript/#comments Sat, 26 Aug 2006 03:02:53 +0000 plains http://www.plasticstare.com/plains/2006/08/25/interfacing-in-actionscript/ It wasn't until recently that I actually had the occasion where it made/makes a good bit of sense to use interfaces in any of my flash projects. Part of the reason has to do with formerly lacking the time to actually put together projects the right way, under crazy timelines, and part of it has to do with the fact that I'm working on something that needs to stick around for a bit and will possibly be augmented by persons other (and including) myself.

In most flash projects, interfaces are a bit convoluted and require thoughtfully building out to what amounts to an extra class. Most of the time in smaller projects, subclassing "default" classes pretty much gets the job done. To backtrack slightly for those unfamiliar with the term, an interface is an abstract type which is used to designate how classes can be accessed and manipulated. To use the terminology, an interface specifies the interface that must be implemented by a set of classes.

Utilizing Interfaces

Interfaces in actionscript are particularly useful when creating a set of classes that all have the same methods; the interface strictly defines the guidelines that must be followed when creating a new class of this type.

As an example, let us suppose that we are creating a set of shape classes; we will be creating a circle class and a square class. Let us suppose for now that the only method that we want to implement is the getArea() method. Here are our classes:

View as Plain Text
Actionscript:
  1. class Circle {
  2.    private var __radius:Number;
  3.    private var __type:String = "Circle";
  4.    
  5.    function Circle() {}
  6.    
  7.    public function getArea():Number {
  8.       return (Math.PI * Math.pow(this.__radius, 2));
  9.    }
  10. }

View as Plain Text
Actionscript:
  1. class Square {
  2.    private var __side:Number;
  3.    private var __type:String = "Square";
  4.    
  5.    function Square() {}
  6.    
  7.    public function getArea():Number {
  8.       return (Math.pow(this.__side, 2));
  9.    }
  10. }

So, both implement the same methods here. We can define an interface for all new shapes that get created, which must all allow for the calculation of their area (note that by convention, interfaces usually begin with the letter "I"):

View as Plain Text
Actionscript:
  1. interface IShape {
  2.    function getArea():Number;
  3. }

You must then go back and change your class definition line in each of the two classes to

View as Plain Text
Actionscript:
  1. class Circle implements IShape {

and

View as Plain Text
Actionscript:
  1. class Square implements IShape {

The interface defines how we can interact with shapes. The big advantage of this when working on projects is that when using environments such as Eclipse with FDT, you can specify that something is an IShape without knowing what shape it is specifically, thereby allowing you to build more flexible projects. In addition, rather than the alternative, which would be to type them as Object, you have a way of typing them that works with syntax checking and code hinting, which saves you time in the long run.

Combining Interfaces with Inheritance

Another handy trick to help when coding is to combine the use of interfaces with inheritance. Let's suppose we want to create a Shape superclass as such:

View as Plain Text
Actionscript:
  1. class Shape extends MovieClip implements IShape{
  2.    private var __type:String = "Shape";
  3.    
  4.    function Shape() {}
  5.    
  6.    public function getArea():Number {
  7.       return undefined
  8.    }
  9.    
  10.    public function setColor(newColor:Number) {
  11.       theColor = new Color(this);
  12.       theColor.setRGB(newColor);
  13.    }
  14.    
  15.    public function toString():String {
  16.       return ("Shape of type: " + this.__type);
  17.    }
  18. }

So, our definitions would change as such:

View as Plain Text
Actionscript:
  1. class Square extends Shape implements IShape {

Now we have a few added benefits. Our shapes are now subclassed as MovieClips and Shapes, which means that they can inherit methods from the Shape class. All of our shapes have a __type and all are now MovieClips, so all of them can inherit toString() and setColor().

The cool part about this is that in this case, we now can implement the IShape interface (remember, all classes that implement an interface are required to implement the designated methods) without declaring ones inherited from the superclass unless we choose to do so. This means that we don't have to add toString() and setColor() unless we want to override the ones in the superclass. This is really great when you have several private variables with getters and setters that you want required by the interface, but don't want to have to duplicate and comment in every single subclass.

Another advantage of using interfaces is that, unlike extending superclasses, classes can implement as many interfaces as you want. For example, you could have a set of Shapes that implement an IAnimation interface as well as the IShape interface. Other types of objects could also implement this same IAnimation interface, so you could call the method pulse(cycleDuration) the same way on both types of class, and your code hinting would tell you that the method pulse requires a number input. This is probably the biggest advantage -- being able to type an object as an interface when passing it to another object that wants to treat it as something that has the methods that the interface requires.

]]> http://www.plasticstare.com/plains/2006/08/25/interfacing-in-actionscript/feed/ 0 Flash/Eclipse/ASDT Empty Class Template http://www.plasticstare.com/plains/2005/11/23/flasheclipseasdt-empty-class-template/ http://www.plasticstare.com/plains/2005/11/23/flasheclipseasdt-empty-class-template/#comments Wed, 23 Nov 2005 23:14:39 +0000 plains http://www.plasticstare.com/plains_wp/?p=59 If you use Eclipse with MTASC and ASDT for working on your actionscript 2.0 classes, one of the handy little features is the ability to create a new class using the ASDT actionscript class creator. However, as you've found out, it sticks in that standard little author tag at the top of your new class. Its not rocket science, but changing this is not completely obvious from the "expert user" style Eclipse interface (read: "not the most usable interface in the world"). In order to create your own standard header for new actionscript classes, you can do the following:

  • In Eclipse, choose File-Preferences
  • Next, in the prefs window, select ActionScript 2
  • Open the Editor sub menu, and choose Templates
  • The first template should be "class" - select it.
  • Click the edit button on the right.

You can now edit your header template for all new class files. I took out "${user}" first, because my user short name on my powerbook is not the author name I wanted to use in my project classes. The "Insert Variable" button is pretty handy as well, as it allows you to choose from a variety of things to add into the template, including the current date and time. This is also handy for adding in any sort of licensing information you might want to throw in there.

After editing, hit the "OK" button and then the "Apply" button in the prefs window, and you should be good to go.

]]> http://www.plasticstare.com/plains/2005/11/23/flasheclipseasdt-empty-class-template/feed/ 0