Where's the Beef?

Particularly galling was Kevin’s pontification exhorting “academics” to get cracking with parallel programming (citing Paul Steinberg) :

If academia treats parallel programming and data structures like a specialized field of study, walled off into a couple courses and ignored by the general curricula, it will be doing a disservice to its students.

First of all universities do teach parallel programming. A new colleague of mine who just received his computer science Ph.D. from Georgia Tech (a southern version of MIT or India’s IIT) knew all about parallel programming; so, it is something that already is taught in “academia.” (That’s where the concepts were invented.)

Second, if we heeded Kevin’s advice, we’d drop the fledgling ActionScript 3.0 courses you can find here and there in universities and go C# big time. That’s because C# (along with Visual Studio 2010) support parallel programming and other than “my own team’s Pixel Bender in Flash” that Kevin mentions, there’s very little support for parallel programming from Adobe—at least support that’s visible and usable like it is with C# and the .NET framework.

Third, while there’s a brisk discussion at OOPSLA (SPLASH) meetings of parallel programming, there’s no one from Adobe there. (I’ve given several presentations using ActionScript 3.0 in design patterns at these meetings but have never met anyone from Adobe—lots from Microsoft though.) So, while MAX is dandy for the Adobe fanboys, and Intel Developers Forums are great for rallying Intel multicore solutions for hardware, the software giants are at OOPSLA where design patterns were invented. You’ll find (like me) that if you’re the dumbest person at a conference, you can learn a lot.

Let me apologize for this mid-week rant, but like a lot of us who are huge supporters of ActionScript 3.0, it’s very frustrating to see languages like C# and Java (and even Python) support parallel programming and then read a post like Kevin’s telling us to “hop to it” while not having the developer tools to do so. Even worse, if we took Kevin’s advice seriously, we’d probably use C# and C++ on the .NET framework and kiss ActionScript 3.0 goodbye.

Chimney allows access to house object

The other day I was working on some getters and setters to capture and encapsulate data passed from an input source. I’m most cognizant of using getters and setters for incoming data so that I have these nice encapsulated chunks of coded properties. The reason behind encapsulation is to keep properties from getting changed by other elements in a program unwittingly. So getters and setters became a recommended way of going about setting up data. (The terms mutators (setters) and accessors (getters) are often used to describe the same thing, but I can’t think of mutators without images of zombies, so I just use getters and setters like everyone else—conformist that I am.)

To be honest, most of the programs that I write using design patterns don’t have getters and setters per se, and I rarely use the ActionScript 3.0 get and set methods. Typically, a well-designed program has no need for explicit getters and setters. Nevertheless, on page 20 of our book, Chandima and I dutifully write about getters and setters as being a mundane aspect of OOP and provide several examples. However, over the years, I’ve seen a growing number of articles about the dark side of getters and setters. The issue is around what getters and setters were meant to do and how they have been misused.

If you think of a house as an object, and the doors as public access, both the opportunities and problems with object access become more apparent. Also, you have places where entry is possible but not intended—such as down the chimney. Anyway, I was moved to pen a season-appropriate missive to shed some light on the issue:

The Night Before OOP-SLA

‘Twas the night before OOPSLA, when all through the watt
Not a coder was stirring, not even a bot;
The downloads were placed on the server with care,
In hopes that St. Singleton soon would be there;
The young geeks were nestled all snug by their screens,
While visions of killer apps arose from their dreams;
And mamma with her iMac, and I with my Dell,
Had just settled down to write code for a spell,
When out on the net there arose such a clatter,
I sprang from my chair to see what was the matter.
Away to the keyboard I cranked up my Flash,
Tore open the folders and emptied the trash.
The apps on the iPod all came alive
Gave the lustre of update to objects on-drive,
When, what on my screen came clear in my glasses,
But a miniature program, and eight tiny classes,
With a little old hacker, so fat like a pork,
I knew in a moment it must be St. Dork.
More rapid than skip lists his coursers they came,
And he whistled, and shouted, and called them by name;
“Now, Factory! now, Context! now, Product and State!
On, Flyweight! on Proxy! on, Builder, Template!
To the top of the dock! to the top of the sprawl!
Now refractor! refractor! refractor all!”
As bits wrapped in packets over the routers do fly
When they meet with an obstacle they return to retry,
So up to the server the coursers they flew,
With program dependencies, errors, and St. Singleton too.
And then, in a twinkling, I picked up my mug
Full of java to seek out each little bug.
As I drew in my mouse, and was clicking around,
Down the accessor St. Singleton came with a bound.
He was messing with properties and methods to boot,
My encapsued objects were wrecked to the root;
A bundle of types he had flung on his back,
And he looked like a newbie overloading the stack.
His eyes — how they glazed! his pimples how icky!
His cheeks were like pizzas, his nose was still sticky!
His droll little mouth had precious few graces,
And when he smiled I was blinded by braces;
The stump of a pencil shown up from his pocket protector,
He stumbled around like Clouseau the inspector;
He had a broad face and was fat as a pie,
When he walked he looked like the Comic Book Guy.
He was chubby and plump, a right jolly old geek,
And I laughed when he tried to give my pattern a tweak;
A wink of his eye and a blast of hot gas,
Soon gave me to know that this guy was crass
He spoke not a word, but started hacking his work,
And filled all the memory; then turned like a jerk,
And laying his finger straight up his nose,
And giving a burp, up the access he rose;
He sprang to his program, to his team issued a command,
And the whole thing crashed like a wave on the sand,
But I heard him exclaim, ere he limped out of sight,

“Happy Coding to all and to all a good night.”

Happy Holidays from Bill and Chandima…

OOPSLA Conference

• The impending ordinariness of teaching concurrent programming
• Mutation Analysis vs. Code Coverage in Automated Assessment of Students’ Testing Skills
• Compiler Construction With a Dash of Concurrency and an Embedded Twist
• Learning OOP with Dynamic Languages: Adding Concrete Strategies to a PHP Strategy Design Pattern
• Manifesto: a New Educational Programming Language

When someone is talking about the “ordinariness” of “concurrent programming” and I had no idea what concurrent programming was, I was a little rattled. However, everything was so interesting that I soon forgot about my own concerns and really got into these other topics. The big deal that hit me between the eyes was concurrent and parallel programming. (One undergraduate student had a presentation on CUDA, which is used in learning concurrent programming—it took him three hours to crank out “Hello World!”) When my turn came, it worked out well, and I survived and even had a good time. The presentation after mine was by three guys who were discussing the process of developing a new language called Grace. SPLASH has a humbling effect. (Click the link below and learn how I met one of the Gang of Four.)

Parallel/Concurrent Programming

For an introduction to Parallel programming and Design Patterns I was advised to look up what Ralph Johnson (one of the Gang of Four) had to say about it. I found the link to a talk Johnson had and now I’m hoping to see an ActionScirpt implementation. If anyone has some tips on any ActionScript 3.0 efforts to introduce concurrent/parallel programming into Flex (Flash Builder) and ActionScript I’d be very interested. Maybe there’s some way to jury-rig a multi-threaded program in ActionScript 3.0. If anyone has more information on this topic or a reference, please pass it along. For all I know, there might be something for concurrent programming with ActionScript 3.0 already.

Rumblings

One of the more persistent themes that I picked up at the conference was an ongoing dissatisfaction with Java. It seems to be the dominant language taught in CS programs, and as it has evolved, it has become more cumbersome more difficult to teach, the libraries have multiplied and the demands keep getting greater. Oddly, those same reasons were given for replacing C++ with something leaner, meaner and less cumbersome—Java. I wonder if ActionScript will grow to the point where it becomes so bloated as to become a Jabba the Hutt language. I hope not.

I had the pleasure of meeting William Pugh, author of skip lists. Like most creative thinkers, Bill has moved on to new challenges but seemed happy to hear that his work on skip list was appreciated.

One Canadian study that cropped found that learning programming languages in CS programs was fairly well-balanced between those who had no experience in programming and those who had at least some. One supposition was that many with programming experience had to unlearn bad habits and relearn OOP programming and problem solving. So for those of you struggling with OOP with little programming experience, you may be better off than those who have had do-it-yourself training in programming. You don’t have to unlearn bad habits.

My 4am Chat with Ralph Johnson

For some years now, I’ve been an early riser—about 4am most days. At the SPLASH conference, which is three time-zones later, it felt like midday getting up at 4am. However, old habits die hard, and I was sitting in the conference area where the wifi was strongest preparing this post for this blog. Other than a cleaning crew, I was the only person there. However, shortly after beginning to write the post, another guy walks in with a cup of what I thought might be coffee and asked him if some were available, and he said it’d be ready about 6am and came over to chat. It turned out that he too was an early riser, and I found out that he was from the University of Illinois. So I inquired whether he knew Ralph Johnson of the Gang of Four. He said, “I am Ralph Johnson.” It turns out that Johnson in addition to being the habitual early riser is quite the raconteur, and for the next couple of hours I learned that his interest in parallel programming went back his doctoral dissertation and how SmallTalk was almost accidentally used in presenting design patterns–plus more tidbits about programming, inventions and personalities in computing than I can begin to remember. What struck me most was that he didn’t seem to be selling his ideas and certainly not design patterns. Design patterns are for creating reusable code and some people used them and others didn’t. Right now he’s interested in patterns for parallel programming, and his current focus is in that area. Anyway, that’s why this post was delayed. When I started writing it, one of the Gang of Four happened to come along.

That's Not The Way I'd Do It

“That’s not the way I’d do it.”

He went on to tell me how he’d do it. After thinking about it a couple of days I realized that the way he’d do it, while not wrong, wasn’t any better than what was originally there. In grousing about it, the chairman of the Computer Science Department remarked,

Yeah, that’s just like a programmer.

While that made me feel better, it was also aggravating. Out of sheer habit, what compels programmers to be so petty? I don’t mind a little one-upmanship, but some discussions need to be about finding a better solution and not forever trying to tell someone how smart you are. (By the way, this isn’t the first time I’ve mentioned this problem in a post, but I’d like this to be an invitational rant and get some reader comments.)

I’ve worked with people in a lot of different fields, and while some pettiness can be found in just about all professions, We’re Number One! when it comes to the That’s not the way I’d do it (TNTWIDI—pronounced tin-widi with a short “i”) syndrome.

Those of us who live in Glass Houses….

For someone who writes a blog about how to program better using OOP and Design Patterns, I’m on pretty thin ice when it comes to grumbling about telling people how to program. Furthermore, most of the comments we get are extremely helpful—let’s face it, we’ve got a pretty smart readership. (That’s due to the topic—not necessarily Chandima and me!) However, at the same time, we get snippish little missives now and again that reflect TNTWIDI, and because we take all comments seriously (unless they’re trying to peddle something), we find it a little aggravating to waste time on what amounts to a bad habit among programmers.

At the same time that we get TNTWIDI, the great majority of comments we get are excellent. For example, in a series of recent interchanges with Timo concerning the Flyweight pattern, we more or less concluded that Timo may have stumbled upon a new design pattern. Likewise, Alan had pointed out a mess I made of certain agile concepts and resulted in my changing a post. Chandima’s posts on Pure MVC has led to a huge number of great comments and given us direction for post content. So, while TNTWIDI is a problem, let’s remember that most of the comments we get are great.

Helpful Comments: Bomb Defusing 101

Imagine you’re working with a number of people to solve problems in defusing bombs. Some of the people have a lot of experience defusing bombs and have studied the chemistry and engineering of bomb-making extensively. Others less so, and still others have no experience and have read little about the topic. Now everybody in the group wants to diffuse bombs successfully. If someone makes a TNTWIDI comment, however, they have to use their method to defuse the bomb.

Such a system would do two things: The TNTWIDI’s would get blown up in short order, and the rest of us would think carefully before we shot off our mouths just to show the group how smart we were. However, there’s a danger in such a practice—it would silence the less experienced. For example, a novice member of the group may ask, “What about a mercury fuse?” Suppose, no one in the bomb defusing group had considered that and a mercury fuse was exactly what a particular bomb used. They’d get blown up because they limited discussion.

Let’s All Get Better

Not too long ago I read an article in which an MIT professor of computer programming/engineering remarked that a certain process that saved a few cycles in the time it took to execute a program was a waste of time. The reason was that it took a huge number of man-hours of programming to save a few milliseconds. In other words the savings would be so small that no one using the program would notice. However, it might take an extra week or month to create such a program. In short, the argument was that many are still acting like we’re using 8-bit processors and 48k of RAM when we’re working with 64-bit processors and RAM measured in gigabytes.

Those particular remarks resonated with me because design patterns focus on human development as much as they do on computer processing. In fact, other than the Flyweight, I cannot think of a single design pattern that speeds up processing. What many fail to understand about design patterns, and why I believe they are so difficult, is that the focus is on relationships between classes. That is the reason that the symbols in the class diagrams are all about describing relationships. If you compare a flowchart with a class diagram, instead of flow control, you see a description of class relationships—or put otherwise—the relationship between participants (those classes, interfaces and subclasses that make up the pattern.)

If our discussions can better focus on relationships, and if we think of relationships when attempting to understand a particular design pattern, we’ll be on the right track. This does not mean that we should not discuss coding. Far from it. Rather, when discussing coding we need to focus on how the code sets up or expresses a given relationship. We need to ask,

Does this code best reflect a given relationship?

You may well ask, How do we determine whether the code reflects the relationship? If that question came to mind; then you’re on the right track.

Let’s hear from you

What are your thoughts about moving ahead in 2010 and beyond with design pattern. Let’s hear from you! Don’t worry, there’s no possible TNTWIDI for this kind of post!

Here are some other speakers you might want to hear/meet:
1. Miško Hevery
Automatic Dependency Injection In The Land Of Dynamic Languages

2. Barbara Liskov (Liskov Principle)
Keynote Speaker

3. Ralph Johnson (GoF)
Regrowing a Language: Refactoring Tools Allow Programming Languages to Evolve

Anyway, just in case any of you will be there, drop by one of the sessions. Everyone’s been very accepting of ActionScript 3.0, and it’d be fun to chat with some fellow ActionScripters!

The other day, I was helping a group who was given a Web site to revive with Flash. The original site was done with PHP, and as I looked at the code, I was struck by the fact that the developer had written some beautiful algorithms in PHP and demonstrated a masterly control over PHP syntax. At the same time, I was struck by the fact that this Humpty Dumpty Web site couldn’t be revised by all the kings horses and all the kings men. A change in one part caused another part to fold and crumble. It was a true house of cards, albeit made with some beautiful cards.

That’s when the metaphor of Mansions in the Slum popped in my head. A lot of developers want to be better at what they develop, and yet while their algorithms shimmer and glow (like a big gorgeous mansion), the relations between the classes and their encapsulated algorithms are cluttered with junk, weeds or are wholly non-existent. When first encountering Design Patterns a lot of developers reasonably ask, How do design patterns make my programs run faster and better?. With few exceptions, such as the Flyweight Pattern, they answer is,

They don’t.

Design patterns help clear the junk and weeds out of the streets between the classes that have been so painstaking developed. Further, design patterns facilitate application maintenance. If you need a little maintenance work in Beverly Hills, it’s easy to get the repair crew in there to do the work, and the house next door isn’t going to collapse when the repair is complete. The community is kept in good shape by good maintenance and a good system of communication. If for some reason, no maintenance was able to get to the homes in Beverly Hills, in short order, the place would deteriorate. However, because of the attention given to the streets that connect all of the mansions in Beverly Hills, we can expect it to be an area of well-maintained homes for the foreseeable future.

So when designing an application, Web site or other program, don’t just think in terms of building great classes with slick algorithms. Think in terms of creating a community of classes where every class can easily relate to other classes but maintain a loose relationship. Not only will that help you maintain your work, but it will help you appreciate and understand what design patterns are all about. The fact that the patterns already have the class relations laid out for you just makes it all that much easier.

In a recent post I voiced my admiration for artists, designers and animators but noted that they seem to have been left out in the cold with ActionScript 3.0. I added a little helper statement not in the ActionScript 3.0 documentation—MovieClip.addFrameScript(). The idea was to encourage artists not to be too hasty in giving up on coding altogether.

Quite frankly, I was surprised by the number of comments we received on that post. I didn’t think artists bothered with our kind of discussions, and was more than a little gratified to find that some of our readers identified with the issues discussed. So I started thinking about a series of posts for helping artists.

I didn’t want to do a “dumbed down” ActionScript 3.0 for artists; so I opted for an approach that would cover the same principles that we’ve discussed throughout the life of this blog. However, I would move more deliberately and touch more bases—especially the basics of OOP. Further, I decided to use video and take advantage of the new Quicktime Player that comes with Screen Sharing. So, I created a simple class to start things off, and put it in an .f4v file (H.264 format) and you can download it by clicking the download button:

You will need an Adobe Media Player that is free to download. I did not include any .fla files because I’d have to put in at least two because some have CS3 and others CS4; so you’ll have to use your own .fla files. Each video is short and will play full screen using the Adobe Media Player. The only thing I need is feedback to let me know whether this kind of thing is helpful or not. I will be focusing on graphics and loading graphics, but I welcome ideas from one and all.

For me, graphic designers and artists are angels. No matter how I try, I can only get so far in graphic design. Tools like clip art, templates, and Kuler help me achieve not awful , but that’s it. (I can even screw up clip art.) So, for anything serious, I’ve got to work with graphic artists. That’s no problem—I like working with angels.

Some graphic artist have made the transition to some version of ActionScript, but with ActionScript 3.0 most complained that they were getting left behind. Early Flash had few ActionScript options and a system for entering code that didn’t require any programming background at all. With ActionScript 2.0, things got better for developers, but designers started voicing concern over increased complexity. With ActionScript 3.0 and the loss of the ability to put code into buttons and MovieClip objects directly, some graphic artists became furious with Flash over what they saw as a betrayal. It was like a carload of kids on the way to do something fun ditched the artists and designers on the roadside.

Other than a handful of developer/designers, most designers aren’t going to become competent with ActionScript 3.0, let alone OOP or design patterns—just like I’m never going to be a competent designer or artist. So I was thinking an interesting project for this blog would be to develop some “Clip Code” for artists. However, I’m not sure what kind of code they’d need. Most of the “Clip Art” that I use is from photographs, but while I know the kind of artwork I need, I don’t know what kind code graphic designers need.

In the same way that I don’t want to have shoddy graphics or photographs (I can do that myself), the “Clip Code” I have in mind is grounded in good but simple design patterns and OOP that artists can use. So, I’d like to throw that one out to the readers of this blog for ideas of what would be useful to graphic designers.

Animation and Dante’s 10th Circle of ActionScript Hell

We all remember from our Italian Literature course that Dante Alighieri’s Divine Comedy describes hell as having nine circles—the last circle being reserved for treason. Were Dante an ActionScript developer, he’d have a 10th Circle for those animators who spread 50 little ActionScript code blocks all over the timeline in different frames and on different layers. (In the last mention of Dante’s inferno on this blog, we only got to the 9th circle.)

Don’t get me wrong. I love animation, and in fact I got Flash initially so that I could do animations on the Web. When first working with Flash, I ran out and got Tony White’s The Animator’s Workbook: Step-by-Step Techniques of Drawn Animation, and I was delighted with what Flash could do following traditional animation techniques. (Joe Cartoon is still one of my heroes.)

What drives me nuts is using animations for some little effect that will be forgotten after one or two views that screw up an entire application. I’m convinced that animation is the sine qua non of Flash, and so I would never suggest that it be reduced in any way. Rather, I think that animation in movie clips needs to be controlled outside of the confines of code embedded in frames and the timeline. For example, pressing the green Play button shows a simple movie clip added to an existing fire-the-weapon animation:

The relevant code for the operation is the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

package
{
	import flash.display.Sprite;
	import flash.media.Sound;
	import flash.media.SoundChannel;
	import flash.net.URLRequest;
	import flash.events.MouseEvent;
	import flash.display.MovieClip;
	import flash.events.Event;
 
	public class Client extends Sprite
	{
		private var m249:MovieClip=new M249();
		private var mc:MovieClip;
		private var weapon:SoundChannel;
		private var url:String = "M249.mp3";
 
		public function Client()
		{
			m249.addEventListener(MouseEvent.CLICK,fireWeapon);
			m249.x = 50,m249.y = 60;
			addChild(m249);
			m249.gotoAndStop(1);
		}
 
		private function fireWeapon(e:MouseEvent):void
		{
			playOnce(m249);
			var urlReq:URLRequest = new URLRequest(url);
			var gun:Sound=new Sound();
			gun.load(urlReq);
			weapon = gun.play();
		}
 
		private function playOnce(mc:MovieClip)
		{
			this.mc=mc;
			this.mc.play();
			this.mc.addFrameScript(mc.totalFrames-1,reset);
		}
 
		function reset()
		{
			this.mc.gotoAndStop(1);
		}
	}
}

The m249 instance is of a movie clip that uses a shape tween to simulate muzzle flashes. (The sound routine was borrowed from another application.)

Initially, the problem I encountered, and I am sure all Flash animators encounter, is the requirement of keeping at least some code on the timeline. After a few false starts, I was able to control it with relatively simple functions with no timeline code. The above code simply represents the possibility of allowing animators to do whatever they want while not worrying about code.

Thanks to Steve Mathews and Colin Holgate who introduced me to the undocumented MovieClip.addFrameScript(), I was able to stop the looping movie clip after a single iteration. My initial solution used Event.ENTER_FRAME, but I liked that offered up by Steve and Colin better. Anyway, there’s a good post on addFrameScript() at Troy Gardner’s blog if you’d like to learn more about it. Like all undocumented code, I’m often at a loss to understand why it’s undocumented.

The huge advantage of an approach that is not in anyway tied to the timeline is re-usability. If all of the coding is external to the development of the movie clip with the animation, there’s less worry about getting tangled up in unknown code lurking on the timeline. You can reuse the animating movie clips with the assurance that what you see is what you get and you can add code without tangling it up with code tucked away in some unseen layer on an unseen frame.

For complex animations, planning is essential, and I’d like to find out what animators would find useful included in the examples and projects examined on this blog. Like artist, animators work is some kind of context and I’d like to refactor animations so that no timeline code is included in the application of the animations.

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.

Looking at the principle in this new light, we can see how it works with a simple example. Suppose you’re doing a lot of work with Shape class objects. Right away you need circles and rectangles, but you might need other shapes later. So to get started, you set up your classes that you know you’ll need, but you want to leave the door open for easy extension. To get started you create an abstract class that leaves an abstract method to add different shape types. The following script is your initial starting point:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package
{
	import flash.display.Shape;
	import flash.display.Sprite;
	import flash.errors.IllegalOperationError;
 
	//Asbstract class do not instantiate
	public class IOpenClosed extends Sprite
	{
		protected var shape:Shape=new Shape();
 
		protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			throw new IllegalOperationError("Abstract method: must be overridden in a subclass");
		}
 
		public function setShape(fillCol:uint,borderCol:uint,lw:Number,rw:Number,h:Number,c:Number):void
		{
			shape.graphics.beginFill(fillCol);
			shape.graphics.lineStyle(lw,borderCol);
			makeShape(rw,h,c);
			shape.graphics.endFill();
			addChild(shape);
		}
	}
}

You will notice that the makeShape() function in the setShape() method only has three parameters. That’s because the first two parameters are the x and y positions. These will be set to 0 using a literal. The stage position is placed using an instance of the shape.

Next, two little classes extend the abstract class to make the circle and rectangle. First the circle-making class extends the abstract class and then overrides the makeShape() function to add the graphics method for creating a circle .

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCround extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawCircle(0, 0, rw);
		}
	}
}

Next, we do the same thing for a rectangle.

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCrectangle extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawRect(0, 0, rw, h);
		}
	}
}

Okay, we’re all done. We’ll create a Client class to test it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package
{
	import flash.display.Sprite;
	//Parameters for setShape are:
	//setShape(fillCol:uint,borderCol:uint,lw:Number,rw:Number,h:Number,c:Number):void
 
	public class Client extends Sprite
	{
		private var rec:IOpenClosed=new OCrectangle();
		private var cir:IOpenClosed=new OCround();
		private var rndrec:IOpenClosed=new OCroundrec();
 
		public function Client()
		{
			rec.setShape(0xC03000,0x32331D,4,100,60,0)
			rec.x=50, rec.y=50;
			addChild(rec);
 
			cir.setShape(0x787746,0x40411E,4,50,0,0)
			cir.x=100, cir.y=200;
			addChild(cir);
		}
	}
}

When tested, we can see that we get our shapes as shown in Figure 1.

Figure 1: Two shapes created with common interface

Obviously not rocket science, but it’s a handy tool for setting up different kinds of shapes.

What about Rounded Rectangles?

This part is the important part as far as both the Open/Closed principle and design patterns are concerned. Suppose you decide you need a rounded rectangle. With the Open/Closed principle in mind, you cannot modify the code but you can add to it through extension. So, let’s add a rounded rectangle:

1
2
3
4
5
6
7
8
9
10

package
{
	public class OCroundrec extends IOpenClosed
	{
		override protected function makeShape(rw:Number,h:Number,c:Number):void
		{
			shape.graphics.drawRoundRect(0, 0, rw,h,c);
		}
	}
}

That wasn’t hard. Add the following lines to the Client, and let’s test it:

1
2
3
4
5

private var rndrec:IOpenClosed=new OCroundrec();
….
rndrec.setShape(0x32331D,0xC03000,4,100,60,24)
rndrec.x=200, rndrec.y=50;
addChild(rndrec);

Figure 2 shows that a rounded rectangle has joined the circle and the rectangle on the stage:

Figure 2: A third shape is created through extension.

As you can see, while it was more work to set it up initially, it’s a lot less work to create new shapes. Also, requesting the shapes in the clients is very simple as well.

Into the Lunch Bucket

Here’s a handy and simple principle that you can see reflected in many different design patterns. For example, the Decorator, Composite, and Builder offer change through extension. So, to add this principle to your lunch bucket, add a class that creates ellipses. If you can do that, you can both understand the principle and apply it. That means it’s ready for work. Figure 3 shows the missing ellipse:

Figure 3: Test your understanding by adding an ellipse to the mix.

One caveat to using this principle is one of the first design pattern principles: favor composition over inheritance. That doesn’t mean you cannot create new elements for your program using extension—clearly some design patterns do so. Rather, just keep in mind that the principles in both OOP and design patterns work in conjunction with one another and you need to realize that not all OOP solutions are grounded in a single principle.

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.

A Simple Practice

As a principle, the Liskov Substitution Principle is easy to carry around in your pocket. If you write the following line in your Client (or even your Factory) you’re doing something wrong:

myObj:SubClassA = new SubClassA();

You know that another subclass of the same base class cannot be substituted for SubClassA. If you attempt to substitute SubClassB for myObj, it will fail. Now, instead, all you have to remember is to write,

myObj:ParentClass = new SubClass();

That’s (just about) it! Well, one more thing. The parent class needs to be an abstract class or an interface. Now, that’s it! How difficult is that to remember?

LSP in the Weird World

In looking at examples of the LSP principle, the two that pop up the most are the rectangle/square and ellipse/circle conundrums. We’ll use the rectangle/square example and try to provide two different alternatives to illustrate programming with LSP and without LSP.
Beginning with the geometric observation, all squares are also rectangles, we’re likely to create a structure like that shown in Figure 1:

Figure 1: Square is a child of Rectangle

After all, we can envision a square as nothing more than a rectangle with equal sides. So an operation such as,

makeRectangle(w,h);

is an effective way to make either a square or rectangle. We add the Square class simply to examine the LS Principle; otherwise creating rectangles or squares would be accomplished using the makeRectangle(w,h) method making sure that w and h are equal when making squares. The inheritance path clearly indicates that a Square object IS A Rectangle. (That is, the two have an IS A relationship.) However, because Rectangle is a concrete class if I substitute Rectangle for Square, I’m going to have to change the type. I cannot substitute an instance of Rectangle for an instance of Square. This violates the Liskov Substitution Principle.
Now, consider Figure 2. Instead of having Square as a child of Rectangle, both Square and Rectangle are children of the abstract class Boxes.

Figure 2: Abstract Class is Parent of both Squares and Rectangles

If I have an instance of Boxes, I can substitute either Square or Rectangle for the instance. In looking at an example, the Client is where we can expect to see the substitution principle at work. In the following example, the Client has a single object (subThis) typed as Boxes. However, that single object can gingerly create either a square or rectangle without the Client knowing the difference. It is designed to illustrate LSP.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

package
{
	import flash.display.Sprite;
	import fl.controls.Button;
	import flash.events.MouseEvent;
 
	public class Client extends Sprite
	{
		private var subThis:Boxes;
		private var rec:Button=new Button();
		private var squ:Button=new Button();
 
		public function Client()
		{
			//Constructer adds buttons
			rec.x = 100,rec.y = 50;
			rec.width = 65;
			rec.addEventListener(MouseEvent.CLICK,doRec);
			rec.label = "Rectangle";
			addChild(rec);
 
			squ.x = 170,squ.y = 50;
			squ.width = 65;
			squ.addEventListener(MouseEvent.CLICK,doSquare);
			squ.label = "Square";
			addChild(squ);
		}
 
		private function doSquare(e:MouseEvent):void
		{
			if (subThis)
			{
				removeChild(subThis);
			}
			subThis=new Square();
			subThis.createBox(70,0);
			subThis.x = 100,subThis.y = 100;
			addChild(subThis);
		}
 
		private function doRec(e:MouseEvent):void
		{
			if (subThis)
			{
				removeChild(subThis);
			}
			subThis=new Rect();
			subThis.createBox(100,70);
			subThis.x = 100,subThis.y = 100;
			addChild(subThis);
		}
	}
}

The Client has two methods to create either a square or rectangle. However, both methods use the object subThis typed as Boxes. Using Boxes.createBox() (subThis.createBox()) the Client substitutes the Square and Rectangle for the Boxes object. Everything works smoothly. The way the program is set up when one is used, the box image changes from a square to a rectangle (or vice versa), but if you wanted, you could create as many as you want and splash them all over the stage. Figure 3 shows what you will see in the current setup.

Figure 3: Substituting Square and Rectangle Subclasses for Boxes Object

With this simple program, you should be able to see the ramifications for larger programs. In fact, the more your program grows, the more important LSP becomes. If you know that you can substitute any derived class for a base class, you are less likely to have unpleasant surprises. As a program grows and changes, you will have more modules, more objects, and more methods that need to interact in a program. The LSP helps keep those relations functional.

The Base Class

After working with the LS Principle, I wondered,

…is there any reason to create a concrete base class? 

The answer is no.

Not a single design pattern has a structure with a concrete parent class.

What do I ever need a concrete parent class for? I can load up a parent class with functionality that can be used with subclasses, but I need some kind of wiggle room for the subclasses to extend the base class. Following the open/closed principle (“Open for extension. Closed for modification”), I can extend with added functionality from a superclass but I don’t want to modify it.

The following base class (Boxes) has a single method and imports the essential Sprite class needed for the graphics. The concrete classes override the function but they both inherit the Sprite class embedded in the base class.

1
2
3
4
5
6
7
8
9
10
11
12
13

package
{
	//abstract class
	import flash.display.Sprite;
 
	public class Boxes extends Sprite
	{
		public function createBox(w:Number,h:Number):void
		{
			//Abstract content
		}
	}
}

In an odd choice, ActionScript 3.0 has Graphic methods for a circle (drawCircle) and an ellipse (drawEllipse), but not for a square –only a rectangle (drawRect). In order to create an equivalent square and rectangle pair, I used the new Player 10 ActionScript 3.0 drawPath() method. (If you’re using Flash CS3 or versions of Flex prior to 3.2, alternative Square and Rectangle classes can be found at the end of this post.) In looking at the concrete classes, there’s not much difference other than the second parameter in the Square class is a dummy variable that is happy with number you stick there. The first parameter (h) is passed to a side variable (s) and only that single value determines the width and heights, which, of course, must be equal. First, you have the Rect class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package
{
	public class Rect extends Boxes
	{
		private var recCmds:Vector.;
		private var recCoord:Vector.;
 
		public override function createBox(w:Number,h:Number):void
		{
			recCmds = new Vector.(5,true);
 
			recCmds[0] = 1;
			recCmds[1] = 2;
			recCmds[2] = 2;
			recCmds[3] = 2;
			recCmds[4] = 2;
 
			recCoord = new Vector.(10,true);
 
			recCoord[0] = 0;//x
			recCoord[1] = 0;//y
			recCoord[2] = w;//width
			recCoord[3] = 0;
			recCoord[4] = w;//width
			recCoord[5] = h;//height
			recCoord[6] = 0;
			recCoord[7] = h;//height
			recCoord[8] = 0;
			recCoord[9] = 0;
 
			graphics.beginFill(0x990000);
			graphics.drawPath(recCmds, recCoord);
		}
	}
}

Next, the Square class is similar, but notice the “dummy” label for the second parameter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

package
{
	public class Square extends Boxes
	{
		private var recCmds:Vector.;
		private var recCoord:Vector.;
		private var s:Number;
 
		public override function createBox(w:Number,dummy:Number):void
		{
			s = w;
 
			recCmds = new Vector.(5,true);
 
			recCmds[0] = 1;
			recCmds[1] = 2;
			recCmds[2] = 2;
			recCmds[3] = 2;
			recCmds[4] = 2;
 
			recCoord = new Vector.(10,true);
 
			recCoord[0] = 0;//x
			recCoord[1] = 0;//y
			recCoord[2] = s;//width
			recCoord[3] = 0;
			recCoord[4] = s;//width
			recCoord[5] = s;//height
			recCoord[6] = 0;
			recCoord[7] = s;//height
			recCoord[8] = 0;
			recCoord[9] = 0;
 
			graphics.beginFill(0x009900);
			graphics.drawPath(recCmds, recCoord);
		}
	}
}

As you can see, no rocket science is involved in either the drawing classes and their base class or the Client class. A single method is used to generate either, and the only real difference between the child classes is the enforcement of the equal width and height in the Square class.

LSP Lunch Bucket Rule

What can we take to work with the Liskov Substitution Principle? It’s nice to know and understand why the principle is in place, but who needs to have all of the implied tentacles of the principle rattling around in your head—especially considering the way Liskov stated it. We know the principle as you should be able to substitute any derived class from a base class where an instance of the base class exists. After further examination, the only way to do that is to use an abstract class or interface for all of your inheritance and implementations. Put more succinctly, the Lunch Bucket Rule is,

Only subclass from abstract classes. Do not inherit from concrete classes.

That’s easy enough to remember. Put that in your head and see if it helps move an OOP and Design Pattern agenda along at work.
\- – - – - – - – - – - — – - – - – - – - – - — – - – - – - – - – - — – - – - \

Flex client and Rect and Square Classes for Flash CS3 and Flex prior to 3.2

First, if you’re using Flex, you might want to use the following mxml program for your client (Ignore the Client.as class if you do):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
	<mx:Script>
		<![CDATA[
		import flash.display.Sprite;
 
		private var subThis:Boxes;
 
		private function doSquare():void
		{
			if ( subThis && rawChildren.contains(subThis) ) rawChildren.removeChild(subThis);
 
			subThis=new Square();
			subThis.createBox(70,0);
			subThis.x = 100,subThis.y = 100;
			rawChildren.addChild(subThis);
		}
 
		private function doRec():void
		{
			if ( subThis && rawChildren.contains(subThis) ) rawChildren.removeChild(subThis);
 
			subThis=new Rect();
			subThis.createBox(100,70);
			subThis.x = 100,subThis.y = 100;
			rawChildren.addChild(subThis);
		}
 
		]]>
	</mx:Script>
	<mx:Button x="100" y="76" label="Square" click="doSquare()" id="squ"/>
	<mx:Button x="200" y="76" label="Rectangle" id="rec" click="doRec()"/>
</mx:Application>

Here’s the Rect class:

1
2
3
4
5
6
7
8
9
10
11

package
{
	public class Rect extends Boxes
	{
		public override function createBox(w:Number,h:Number):void
		{
			graphics.beginFill (0x990000);
			graphics.drawRect (0,0,w,h);
		}
	}
}

And now the Square class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package
{
	public class Square extends Boxes
	{
		private var s:Number;
 
		public override function createBox(w:Number,dummy:Number):void
		{
			s=w;
			graphics.beginFill (0x009900);
			graphics.drawRect (0,0,s,s);
		}
	}
}