Several years ago I wrote an article on using abstract classses and interfaces in Java . Back than I was absolutely sure that writing object-oriented code is a must. These days, I’m using yet another language called ActionScript 3 (AS3), which supports all OOP paraphenalia plus has provisions for dynamic data types. This article illustrates my up to date vision of OOP with and without interfaces. OK, let’s go.
You know the drill: a language is called object-oriented if it supports inheritance, encapsulation and polymorphism. The first two notions can be easily defined:
• Inheritance allows you to design a class by deriving it from an existing one. This feature allows you to reuse existing code without doing copy and paste. AS3 provides the keyword extends for declaring class inheritance, for example:
package com.theriabook.oop{
public class Person {
var name:String;
}
}
package com.theriabook.oop{
public class Consultant extends Person{
var dailyRate:Number;
}
}
package com.theriabook.oop{
public class Employee extends Person{
var salary:Number;
}
}
Listing 1. The ancestor and two descendents
• Encapsulation is an ability to hide and protect data. AS3 has access level qualifiers such as public, private, protected and internal to control the access class variables and methods. In addition to a Java-like public, private, protected and package access levels, in AS3 you can also create namespaces that will give you yet another way of controlling access to properties and methods. However, if Java enforces object-oriented style of programming, this is not the case with AS3, because it’s based on the scripting language standard. Object-oriented purists may not like the next code snippet, but this is how HelloWorld program may look in AS3:
trace(“Hello, world”);
That’s it. No class declaration is required for such a simple program, and the debug function trace() can live its own class-independent life, as opposed to Java’s println() doubly-wrapped in the classes System and PrintStream. You can write your own functions, attach them to dynamic objects and pass them as parameters to other functions. AS3 supports regular inheritance chain as well as so-called prototype inheritance when you can add new properties to the class definitions, and they will be available to all instances of this class. Moreover, you can disable validation of the properties and methods during compilation by turning off “strict” mode. In Java, behind every object instance there is an entity of type Class. This is not an object itself, but it’s placed in memory by class loaders.
Program Design with Interfaces and Polymorphism
As in Java, AS3 interfaces are special entities that define the behavior (methods) that can be implemented by classes using the keyword implement. After explaining crucial for OOP interfaces, we’ll discuss how to write generic code even without their.
To illustrate how you can design AS3 programs with interfaces, let’s work on the following assignment:
A company has employees and consultants. Design classes to represent people working in this company. The classes may have the following methods: changeAddress, giveDayOff, increasePay. Promotion can mean giving one day off and raising the salary by a specified percentage. For employees, the method increasePay should raise the yearly salary and, for consultants, it should increase their hourly rate.
First, we’ll add all common methods that are applicable to both employees and consultants to the class Person.
package com.theriabook.oop {
public class Person {
var name:String;
public function changeAddress(address: String): String {
return “New address is” + address;
}
private function giveDayOff(): String {
return “Class Person: Giving an extra a day off”;
}
}
}
Listing 2. The Ancestor class: Person
In the next step, we’ll add a new behavior that can be reused by multiple classes: an ability to increase the amount of a person’s paycheck. Let’s define an interface Payable:
package com.theriabook.oop
{
public interface Payable
{
function increasePay(percent:Number): String;
}
}
Listing 3. Interface Payable
More than one class can implement this interface:
package com.theriabook.oop
{
public class Employee extends Person implements Payable
{
public function increasePay(percent:Number):String {
// Employee-specific code goes here …
return “Class Employee:Increasing the salary by “+ percent + “%\n”;
}
}
}
Listing 4. AS3 class Employee implementing Payable interface
package com.theriabook.oop
{
public class Consultant extends Person implements Payable {
public function increasePay(percent:Number): String{
// Consultant-specific code goes here …
return “Class Consultant: Increasing the hourly rate by ” + percent + “%\n”;
}
}
}
Listing 5. Class Consultant implementing Payable
When the class Consultant declares that it implements interface Payable, it “promises” to provide implementation for all methods declared in this interface – in our case it’s just one method increasePay(). Why is it so important that the class will “keep the promise” and implement all interface’s methods? An interface is a description of some behavior(s). In our case the behavior Payable means existence of a method with the signature
boolean increasePay(int percent).
If any other class knows that Employee implements Payable, it can safely call any method declared in the Payable interface (see the interface example in class Promoter).
In Java, besides method declarations, interfaces can contain final static variables, but AS3 does not allow in interfaces anything but method declarations.
Interfaces is yet another workaround for the absence of multiple inheritance. A class can’t have two independent ancestors, but it can implement multiple interfaces, it just needs to implement all methods declared in all interfaces. One of the way to implement multiple ingeritance (we often use but do not recommend – use at your own risk) is to use “include” statement with complete implementation in all classes implementing interface:
public class Consultant extends Person implements Payable {
include “payableImplementation.as”
}
public class Employee extends Person implements Payable {
include “payableImplementation.as”
}
For example, a class Consultant can be defined as follows:
class Consultant extends Person
implements Payable, Sueable {…}
But if a program such as Promoter.mxml (see below) is interested only in Payable functions, it can cast the object only to those interfaces it intends to use, for example:
var emp:Employee = new Employee();
var con:Consultant = new Consultant();
var person1:Payable = emp as Payable;
var person2:Payable = con as Payable;
Now we’ll write a MXML program Promoter, which will use classes Employee and Consultant defined in the Listing 4 and 5. On the button click it’ll create an array with a mix of employees and consultants, iterate through this array and cast it to Payable interface, and then call the method increasePay() on each object in this collection.
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute”>
<mx:Label y=”10″ text=”Inheritance, Interfaces and Polymorphysm” width=”398″ height=”35″ fontWeight=”bold” horizontalCenter=”-16″ fontSize=”16″/>
<mx:Button x=”93″ y=”66″ label=”Increase Pay” width=”172″ fontSize=”16″ click=”startPromoter()” id=”starter”/>
<mx:TextArea x=”26″ y=”114″ width=”312″ height=”133″ id=”output” wordWrap=”true” editable=”false” borderStyle=”inset”/>
<mx:Script>
<![CDATA[
import com.theriabook.oop.*;
function startPromoter():void{
output.text="Starting global promotions...\n";
var workers:Array = new Array();
workers.push(new Employee());
workers.push(new Consultant());
workers.push(new Employee());
workers.push(new Employee());
for(var i: int = 0; i < workers.length; i++) {
// Raise the compensation of every worker using Payable
// interface
var p: Payable = workers[i] as Payable;
output.text+= p.increasePay(5);
//p.giveDayOff(); would not work. Payable does not know
// about this function
}
output.text+=”Finished global promotions…”;
}
]]>
</mx:Script>
</mx:Application>
Listing 6. Promoter.mxml
The output of this program will look as follows:
The line p.increasePay(5); in the listing above may look a little confusing: how can we call a concrete method increasePay on a variable of an interface type? Actually we call a method on a concrete instance of the Employee or a Consultant object, but by casting this instance to the type Payable we are just letting the AVM know that we are only interested in methods which were declared in this particular interface.
• Polymorphism – when you look at our Promoter from Listing 6, it looks like it calls the same method increasePay() on different types of objects, and it generates different output for each type. This is an example of polymorphic behavior.
In the real world, array workers would be populated from some external data source. For example, a program could get the person’s work status from the database and instantiate an appropriate concrete class. The loop in Promoter.mxml will remain the same even if we’ll add some other types of workers inherited from the class Person! For example, to add a new category of a worker – a foreign contractor, we’ll have to create a class ForeignContractor that implement the method increasePays and might be derived from the class Person. Our Promoter will keep casting all these objects to the type Payable during the run-time and call the method increasePay of the current object from the array.
Polymorphism allows you to avoid using switch or if statements with the type checking operator is. Below is a bad (non-polymorphic) alternative to our loop from Promoter.mxml that checks the type of the object and calls type-specific methods increaseSalary() and increaseRate() (assuming that these methods were defined):
for(var i: int = 0; i < workers.length; i++) {
var p: Person = workers[i] as Person;
if (p is Employee){
increaseSalary(5);
} else if (p is Consultant) {
increaseRate(5);
}
}
Listing 7. A bad practice example
You’d need to modify the code above each time you add a new worker type.
Polymorphism without interfaces
If this would be a Java article, I could have patted myself on the back for providing a decent example of polymorphism. But I’d like to step into a little bit dangerous territory: let’s think of a more generic approach – do we even need to use interfaces to ensure that a particular object instance has a required function like increasePay? Of course not. Java has a powerful introspection and reflection mechanism, which allows to analyze which methods exist in the class in question. It’s important to remember though, that in Java object instances have only those methods that were defined in their classes (blueprints). This is not the case with AS3.
There is yet another urban myth that reflection is slow, and you should use it only if you have to. But this consideration is not valid for programs that run on the client’s PCs, because we do not have to worry about hundreds of threads competing for a slice of time of the same server’s CPU(s). Using reflection on the client is fine. Even on the server, a proper combining of reflection with caching allows avoiding any performance penalties.
AS3 provides very short and elegant syntax for introspection, and we’d like to spend some time illustrating polymorphism without typecasting and strict Java-style coding.
Let’s re-visit our sample application. Workers have pay and benefits and vacations, consultants have hourly pay. But retirees may have some other forms of receiving pension, board of directors might have pay with no benefits – are they workers? No they are not, and their objects may not necessarily implement Payable interface, which means that the typecasting from Listing 6 would cause a run-time exception.
How about raising the compensation of every Person even if it does not implement Payable? If one of these objects will sneak into the array of workers, simple casting to Payable show below will throw an exception
Payable p = Payable(workers[i]);
Let’s re-write the loop from Listing 6 as follows:
for(var i:uint = 0; i < workers.length; i++) {
var p:* = workers[i]["increasePay"];
output.text+=p==undefined?”no luck”:p(5);
}
This short loop deserves explanations. First, we’ve declared a variable p of type *. Using an asterisk a bit more open than var p:Object; as it allows the variable p to have a special value of type undefined, which is used in the above code sample.
Let’s dissect the following line:
var p:* = worker[i]["increasePay"];
It means, “Get a reference to the function increasePay() from the array element workers[i]. You may ask, why do you use brackets around the increasePay instead of the dot notation? The reason being that dot notation would ask the compiler to find and validate this function, while the brackets tell compiler not to worry about it: the program will take care of this little something inside the brackets during the runtime.
Basically, this single line above performs the introspection and gets a pointer to the function increasePay for the future execution in the next line:
output.text+=p ==undefined?”no luck":p(5);
If this particular element of the workers array does not have increasePay defined (its class must be declared as dynamic), add “no luck” to the text field, otherwise execute this object’s version of increasePay passing the number five as its argument. The line above still has a potential problem if the class does not have the function increasePay, but has a property with the same name. The bulletproof version looks like this:
output.text+=!(p is Function)?"no luck":p(6);
Let’s emphasize again: this method increasePay does not have be defined in any interface.
Java programmers would call this a wild anarchy. Of course, adhering to strict rules and contracts in Java leads to more predictable code and less surprises during the run-time. But modern Java moves toward dynamic scripting, added implicit typecasting, run-time exceptions, etc. Overuse of interfaces, private, protected and other “nice and clean object-oriented techniques” does not promote creative thinking of software developers. By the way, protected variables is another weird thing in OOP.
Summary
Now raise your hand if you are a Java programmer and after reading this article you are thinking to yourself, “Hmm, may be ActionScript 3 is not too bad and I should take a look at it ?”.
Now, stand up if you are thinking, “Java rules, the rest of programming languages sucks”.
ActionScript 2 programmers can remain seated, but might want to reconsider the way they program.
Yours truly,
Yakov Fain
