Monthly Archive for February, 2009

OOP & Designs Pattern Principles: Ready for Work

Published on February 26, 2009 in AIR, Design Patterns at Work and Principles. by William B. Sanders 11 Comments

airimgThis post is going to be short and sweet. I worked up a little application that you can see here. Also, I created an AIR version, and it now seems to work on Mac, Windows 7, Windows Vista and Windows XP. You’re welcome to download it here (AIR version) and put it someplace handy where you can quickly look up the main principles guiding OOP and design patterns.

Principles in Your Lunch Bucket

Here’s the whole idea of why I started this project in the first place. We need something that makes it easy to remember and use good practices at work. The posts reviewing OOP and DP principles on this blog is one resource, but something simpler (and sillier) would be helpful to have available when cranking out code under a deadline.

Yes, I practiced what is preached

When developing this little application, I started off the wrong way, and decided that no! Never again! I’d start off right, and it wasn’t any more difficult. I used a Strategy pattern, and later I’ll put the whole thing up here with an explanation of how this “work” project was done by following the dictums I was writing about.

So take a look and let me get your valuable (as always) feedback.

  • Share/Bookmark

Design Pattern Principles for ActionScript 3.0: Favor Object Composition Over Class Inheritance

Published on February 21, 2009 in Principles. by William B. Sanders 6 Comments

bucketruleAfter getting slightly comfortable with the first dictum of design patterns, program to an interface; not an implementation, you may find this next one will knock the support blocks right from under you. In being advised to program to an interface, we get the idea that we type our objects to a superclass (abstract class or interface) and then we actually instantiate the object to a concrete class that is derived from the superclass. Doing so optimizes flexibility and minimizes dependency on implementations.

We assume that we are dealing with some kind of inheritance. It doesn’t matter if the inheritance is from an abstract class or pure interface. However, this next principle,

Favor object composition over class inheritance

looks like if we have a choice, we should avoid inheritance altogether. (We doan need no stinkin’ inheritance!)
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Favor Object Composition Over Class Inheritance’

  • Share/Bookmark

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

Published on February 14, 2009 in Abstract Classes, Design Patterns at Work, Polymorphism and Principles. by William B. Sanders 4 Comments

bucketrule1The 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.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: Program to an Interface; not an implementation’

  • Share/Bookmark

Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle

Published on February 8, 2009 in Abstract Classes, Design Patterns, Design Patterns at Work, OOP and Principles. by William B. Sanders 4 Comments

bucketrule2Gentle Reader: Now that we’ve worked through all of the design patterns in ActionScript 3.0 from GoF (well, Builder is still in the works, but that’ll be available soon), now would be a good time start going through the principles underlying design patterns. This will be the first in that series.

The 1987 OOPSLA keynote address by Barbara Liskov contained what has become known as the Liskov Substitution Principle (LSP). Essentially, the principle holds that

If a Client is using a reference to a base class it should be able to substitute a derived class for it without affecting the program’s operation 

(Actually Dr. Liskov said something more like:

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

but I’m not about to…)

If the Client has an object of a certain type, it should be able to substitute a derived object of the same type. For example, suppose you have an abstract class named Automobile and from that class you have subclasses of Ford, Toyota, and Peugeot. Your Client has an object, myAuto:Automobile. The myAuto object can be any of the subclasses, and if a substitution is made for any one of them everything keeps on working without a problem and the change is unknown to the Client. So if you substitute a Ford for a Toyota, the Client can work with the objects without having to adjust for the change. What’s more, if you want to add a Fiat class as a subclass of Automobile, the myAuto object handles it with nary a whimper.

The one caveat is that the subclasses must all honor the contractual conditions of the parent class. So, any methods in the parent class must be functioning in the subclass (aka, derived class.)

Now you may be thinking, So what? If you’re at all familiar with other principles of OOP and Design Patterns, this principle may sound vaguely familiar, but what is the importance of this concept/principle/idea? It is this: Because the Client is unaware of the concrete class that the object may implement, the structure is far more resilient. Not only can the same structure be reused, it can be changed, updated and generally fiddled with without easily breaking anything. (Think of adding more car manufacturers to the Automobile class.) As far as the Client is concerned, as long as the interface rules are followed with the object, everything is hunky-dory.
Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Liskov Substitution Principle’

  • Share/Bookmark