46 | Chapter 1: Object-Oriented Programming, Design Patterns, and ActionScript 3.0
your client dependency leads to unexpected results or fails to run altogether. By
depending on interfaces, your code is decoupled from the implementation, allowing
variation in the implementation. This does not mean you get rid of dependency, but
instead you just manage it more flexibly. A key element of this approach is to sepa-
rate the design from the implementation. By doing so, you separate the client from
the implementation as well.
As we have seen, you can use the ActionScript 3.0interfacestructure or an abstract
class to set up this kind of flexible dependence. However, when you use either, you
must be aware of the way in which to manage the dependency. If you use an
interfacestructure, any change in the interface will cause failure in all the clients
that use theinterface. For example, suppose you have five methods in aninterface.
You decide that you need two more. As soon as you add the two new methods to
your interface, your client is broken. So, if you use theinterfacestructure, you must
treat the interface as set in stone. If you want to add new functionality, simply create
a new interface.
The alternative to using the interface structure is to use abstract classes. While the
abstract class structure is not supported in ActionScript 3.0 as interfaces are, you can
easily create a class to do everything an abstract class does. As we saw in several
examples in this chapter beginning with Example 1-3, creating and using an abstract
class is simply adhering to the rules that abstract classes follow anyway. For exam-
ple, abstract classes are never directly implemented.
The advantage of an abstract class over an interface is that you won’t destroy a client
when you add methods to the base class. All the abstract function must be overrid-
den to be used in a unique manner, but if your client has no use for a new method,
by doing nothing, the method is inherited but not employed or changed. On the
other hand, every single method in aninterface structure must be implemented.
A further advantage of an abstract class is that you can add default behaviors and
even set up concrete methods inherited by all subclasses. Of course the downside of
default behaviors and concrete methods is that a subclass may not want or need the
default or concrete methods, and a client may end up doing something unwanted
and unexpected if any concrete changes are introduced. Whatever the case, though,
management of dependency is easier with the flexibility offered by interfaces and
abstract classes over concrete classes and methods.
So the decision of whether to use an interface or abstract class depends on what you
want your design to do. If the ability to add more behaviors easily is most important,
then abstract classes are a better choice. Alternatively, if you want independence from
the base class, then choose an interface structure. No matter what you do, though,
you need to think ahead beyond the first version of your application. If your applica-
tion is built with an eye to future versions and possible ways that it can expand or
change, you can better judge what design pattern would best achieve your goals.