CSC/ECE 517 Fall 2012/ch2b 2w22 sk

Requirements

The introduction to the GoF book gives three principles for writing reusable and flexible software.

• Program to an interface, not an implementation.
• Favor object composition over class inheritance.
• Consider what should be variable in your design (originally, Encapsulate the behavior that varies).

Explain these principles, and illustrate them with original examples.

Program to an interface, not an implementation

This principle is really about dependency relationships which have to be carefully managed in a large app - Erich Gamma

In this principle, the word interface is more conceptual and should not be seen from the viewpoint of a language like Java or C# which has a keyword by the same name. Interface relates to the OO principle of capabilities that the object(s)is(are) able to support. So by this definition an object can have many types or interfaces, and objects of different classes can have the same interface or type. In this context, the main idea behind this principle is how to decouple the implementation from the interface so that the code can be extended polymorphically ie., to reduce the implementation dependencies.

For example:

So this approach gives you flexibility, but it also separates the really valuable part, the design, from the implementation, which allows clients to be decoupled from the implementation.

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.

Another way to look at it is that you should focus not only on developing version one, but to also think about the next versions. This doesn't mean designing in future extensibility, but just keeping in mind that you have to maintain what you produce and try to keep the API stable for a long time. You want to build to last.

Just by following this rule, you get two very important benefits as stated in the GOF book:

1. Clients remain unaware of the specific types of objects they use, as long as the objects adhere to the interface that the clients expect.
2. Clients remain unaware of the classes that implement these objects. Clients only know about the base/abstract classes or interfaces (C# interface) defining the interface. And this greatly reduces the implementation dependencies.

REFERENCES

<references/> http://www.fatagnus.com/program-to-an-interface-not-an-implementation/
http://www.artima.com/lejava/articles/designprinciples.html
http://blogs.msdn.com/b/sachin/archive/2008/06/12/program-to-an-interface-not-an-implementation.aspx
http://pragmaticjava.blogspot.com/2008/08/program-to-interface-not-implementation.html
http://www.as3dp.com/2009/02/design-pattern-principles-for-actionscript-30-program-to-an-interface-not-an-implementation/
http://www.amazon.com/gp/product/0596007124?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596007124
http://www.amazon.com/gp/product/0201633612?ie=UTF8&tag=fatagnus-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=0201633612