Design Pattern Principles for ActionScript 3.0: Program to an Interface; not an implementation

The first principle of design patterns is,

Program to an interface, not an implementation

Simply put, the Gang of Four urges programmers to declare variables only to abstract classes and interfaces and not concrete implementations. You never want to type your instance as a concrete class derived from an interface or abstract class—only to the interface.

Okay, you may be thinking that we already covered this principle in our book. That’s true. We did in both the introduction (pp. 45-49) and in part of the chapter on the Observer design pattern (pp. 285-288.) We also had a lot of examples, and so why rehash the same principle here? The following reasons seemed compelling enough to warrant additional discussion:

• Includes dynamic binding
• Closely tied to polymorphism
• Built into Creation design patterns
• Easy to ‘take to work’

Before starting, we’ll use the concept of an interface to refer to programs that use either abstract classes or ActionScript 3.0 interface. So, if you see a reference to an interface, it could well be an abstract class. It’s the concept of an interface that’s important; not the ActionScript 3.0 interface statement.

As you read this, you may hear echoes of the Liskov Substitution Principle (LSP). I’m really not sure what relation there is between the LSP and the first GoF principle. Suffice it to say that LSP is part of the back-story (as they say in Hollywood), but only part. During the 1980s and 1990s when a lot of the OOP and Design Patterns concepts were being developed and presented at OOPSLA, ideas were shared. Further, GoF references Abstraction and Specification in Program Development by Barbara Liskov and John Guttag (McGraw-Hill, New York, 1986) so Gamma and his associates were aware of Liskov’s work. But to say that this principle was derived from LSP is a leap that I’m not willing to take. However, I certainly see no contradiction between LSP and GoF’s first principle.

Dynamic Binding, Polymorphism and Interfaces

Polymorphism has been discussed elsewhere on this blog, and we all know it is one of the pillars of OOP. This first principle of design patterns is tied into polymorphism. In order to follow the path from interfaces to polymorphism, we need to start with an operation’s signature. As you know, a signature is made up of the following:

• operation’s name
• objects it takes as parameters
• return value

In this context we can discuss interfaces as all of the operations in an object. For the most part, an object as used by GoF refers to a class and not an instance of a class as the term object is conventionally used. (I won’t belabor the meaning of signatures and interfaces here, but if you want more details on both concepts, see the discussion beginning on page 19 of our book.)

When we type an object, such as,

var myInstance:String;

we tend to think of String as a class type, but in fact it denotes a particular interface. “Any request that matches a signature in the object’s interface may be sent to the object” (GoF 13).

Bumping this up to user created classes, we type to the interface, which is found in the supertype relative to a subtype. That is, a subclasses’ type resides in the parent class. Because all knowledge of an object is known only through its interface, the request does not address the implementation. As a result, objects with different implementations can have the same interface.

Several different objects can have the same interface (primarily based on the superclass) but different implementations, and since the actual operation that is performed is dependent on both the request and receiving object’s name, the actual outcome occurs at run-time. Such an association between the a request and its operation at run-time is known as dynamic binding. The process of dynamic binding lets you substitute objects with identical interfaces at run-time. You probably know this process by another name, polymorphism.

Design patterns help you set up interfaces and use polymorphism in organizing your program. The more you look at the different principles of OOP, the more you can see how these principles are maintained and presented in design patterns. Key are ActionScript 3.0 pure interfaces and abstract classes. All operations in an interface are abstract, but an abstract class can defer some or all implementations to derived classes (subclasses.) Thus, the abstract class is more flexible than the pure interface, but both serve as interfaces

Reducing Implementation Dependencies

Gamma and his associates spell out two key benefits of manipulating objects solely in terms of the interface (of either pure interfaces or abstract classes).

1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that clients expect.

2. Clients remain unaware of the classes that implement these objects. Clients only know about the abstract class(es) defining the interface. (GoF, p. 18)

The whole purpose is to build functional structures but to keep them loose enough for change and reusability. Obviously you have to instantiate concrete classes, but by using the abstract class interface, (instead of the concrete classes’) you provide flexibility in the implementation. All design patterns in the Creational category [Factory Method, Abstract Factory, Prototype, Builder and Singleton*] essentially force you to create your programs in a way that follows this principle. (*I have serious questions as to the Singleton’s ability to do anything very useful along these lines. See this post for details.)

Implementation Lunch Bucket Rule

While GoF’s statement of the principle is very clear once you understand what they mean by an interface, we might be able to re-word it for an even simpler rule to take to work.

Type all objects to the interface of the parent class and never to the child class

Of course the parent and child class share an interface, but the child class (subclass) has concrete implementations.

The best part about this rule is that it is automatically enforced in all creational patterns. So, besides having a simple rule to work with (and bring to work) you have plenty of patterns that automatically set up your program to follow this rule.

The Design Pattern Principles for ActionScript 3.0: Program to an Interface; not an implementation by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.