Archive for the 'OOP' Category

Page 2 of 9

Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle

Published on March 31, 2009 in Design Patterns at Work, Examples, OOP and Principles. by William B. Sanders 2 Comments

bucketrule
In the little AIR menu with the 10 principles one of the clearest is the Open/Closed Principle. At one time this principle suggested that all updates be created using an implementation or extension of virtually any class. That could get tricky, especially if someone understood that to mean implementing an update or extending a subclass. However, later, the extension came to mean the extension of an abstract base class. In other words the interface is extended but never modified. Given these caveats, we can understand the basic principle as it is now understood:

Classes should be open for extension but closed for modification.

Easy to Take to Work

(Note: In talking about a program and changes, we’re not including the Client class. It just makes requests, and you can add requests and change them all you want in the Client.)

The idea that when you want to change a program, the only way you are able to make changes is by extension may seem a little restrictive. However, what the principle is really doing is providing a way to make changes without having to rewrite the whole program. The dictum, New behaviors are only available through extension should not be phrased in a way to make it sound like it’s tying your hands. Rather, it should say something like,

Hey! The Open/Closed principle makes it easy to add new behaviors without having to mess up your whole program.

Continue reading ‘Design Pattern Principles for ActionScript 3.0: The Open/Closed Principle’

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’

Where’s the Real World?: Design Pattern Examples in ActionScript 3.0

Published on January 26, 2009 in ActionScript, Design Patterns, Examples, Flash, Flex and OOP. by William B. Sanders 18 Comments

Gentle Readers: This short post is a request for feedback. The whole issue of appropriate level examples both in our books and this blog is an important one because it speaks to the utility of the writings and posts. So, your thoughts are not only welcomed; they’re essential.

I had a meeting with a computer scientist who was teaching a game class. In our short chat, he must have used the term real world a dozen times. Well, I’m all for the real world (in contrast to the unreal world of unicorns, fairy dust, and honest politicians). However, the real world for one is not the same as it is for another. Recently, I got a comment about a blog entry thanking us for a solution to a practical problem that one of our readers encountered in programming. The same post was criticized by another reader as not being real world. Therein lies the dilemma.

Abstract vs. Concrete

Chandima and I use a range of examples in our book. We start with an abstract minimalist example so that the reader can see the participants in a design pattern and then move on to something more concrete to illustrate a practical application. On this blog, most of the examples start with the more abstract elements and move into a fairly general (somewhat abstract) example that is more practical. The more abstract an example, the more general its applicability—not unlike an abstract class. However, the more concrete an example, the better the reader can use it to model a like problem in an eminently practical way. Each has its benefits. The abstract examples have generalizability and the concrete examples have needed detail.

Were I to do all of my examples using real world examples that I deal with, most would involve streaming video and Flash Media Server. My customers usually approach me for just that kind of problem. Obviously,using streaming video and FMS is real world, but its not very generalizable. Likewise, some readers complain that the abstract examples don’t help because they’re not practical.

We’d like your thoughts on this issue. Obviously, the most useful examples would be those that you deal with directly in your work, but like my practical work, it’s pretty narrow. Keeping these concerns in mind, tell us what’s most helpful to you.

Take a Design Pattern to Work Part IV: Establishing a Design Pattern Foundation

Published on January 15, 2009 in Abstract Classes, Design Patterns, Design Patterns at Work, Factory Method, Flash, Flex and OOP. by William B. Sanders 2 Comments

Gentle Reader: This is Part 4 of a four-part series of posts on introducing design patterns and OOP into the work place. Parts 1 through 3 will provide the context for this part. Also, taking a look at No Time for OOP and Design Patterns will give you the background on this series. As always, we invite your comments.

Note: Chandima wrote the chapter in our book on the Factory Method, and he gave me invaluable help on the main program in this post as well.

Recap

Up to this point we’ve examined a simple program that loads external text and graphics, a common ActionScript chore. In the most general terms, this is where we’ve been:

  • Part I: Identifying the problem in a current solution. Why ActionScript on the Timeline can cause problems.
  • Part II: Providing a simple OOP solution: Use of Inheritance
  • Part III: Loosening Up a programs structure: Adding a design pattern element —a simple factory

To conclude the process, we now come to the last part—introducing an actual design pattern to the work place.

  • Part IV: Establishing a Design Pattern Foundation.

Given the preceding steps, the context is now in place to add a full design pattern.

From Part to Whole

Part III introduced the Simple Factory method inserted into an existing OOP program. Now it’s time to step back and look at a design pattern en toto and instead of incrementally adding to the existing program, we will refactor the whole kit-n-kaboodle from the perspective of a design pattern.

To get started, if you’re not familiar with the Factory Method pattern, take a look at Chapter 2. In fact Chandima’s Sprite Factory example beginning on page 84 is one of the clearest and most appropriate examples that you can find of the Factory Method pattern in ActionScript 3.0. So before continuing, you might want to do a quick review of the Factory Method and take a look at Figure 1, the class diagram for the pattern. (We’ll wait for you…).

factorymethoddp852

Figure 1: Factory Method Design Pattern

As you can see, the Factory Method (simple factory) is part of the Creator interface and the ConcreteCreator. The interface is an abstract class; so at least one of the methods needs to be abstract—impossible to directly instantiate but easily overridden in a child class.
Continue reading ‘Take a Design Pattern to Work Part IV: Establishing a Design Pattern Foundation’

Take a Design Pattern to Work Part III : Loosening Up

Published on January 7, 2009 in ActionScript, Design Patterns, Design Patterns at Work, Flash, Flex and OOP. by William B. Sanders 6 Comments

Gentle Reader:This is Part 3 of a four-part series of posts on introducing design patterns and OOP into the work place. Reading Parts 1 and 2 will provide the context for this part. Also, taking a look at No Time for OOP and Design Patterns will give you the background on this series. More so than most posts, we invite your comments.

Doing the Loosen Up

Few of you remember Archie Bell and the Drells, but their song, Tighten Up was a big hit back in the day. With design patterns, we want to do the opposite, Loosen Up. At this point, we’re going to do the Loosen Up. So put on your dancing shoes and look at the post No New is Good New. The purpose of the post is to get us to think about relationships between objects in a programming design. The dictum, program to an interface and not an implementation is invoked, and the post discusses different kinds of relationships found in design pattern diagrams. If you’re not sure about the issues involved, that post will help understand the next step in introducing design patterns to work.

At this stage in the series, we have arrived at one of the pillars of OOP, inheritance. Figure 1 shows a simple diagram of where we are now in refactoring the original application that used ActionScript on the Timeline.

inheritance

Figure 1: Inheritance from a parent class

As you saw, inheritance allows developers to use the properties and methods of existing classes and in so doing saves time and adds consistency. However, a standard inheritance model also requires the client to instantiate all of the child classes that must be used. True, the instantiation can be through the parent class by initially typing the objects as the parent class rather than the child class as the following shows:

private var hci:Staff;
hci = new HCI();

The purpose of instantiating the parent is to make the link more general and flexible without breaking encapsulation. If the parent class changes, the objects typed to the parent have a better chance of working well without modification.

Continue reading ‘Take a Design Pattern to Work Part III : Loosening Up’