I think that you’ve expressed what a lot of developers experience concerning OOP and design patterns. It reminds me of the 17th Century poet Andrew Marvell’s poem, To his Coy Mistress

Had we but world enough, and time,
This coyness, lady, were no crime.
…
For, lady, you deserve this state,
Nor would I love at lower rate.

But at my back I always hear
Time’s winged chariot hurrying near;….

As all 17th Century literary scholars know, Marvell was really a Fortran I programmer (and did comic books on the side) and his coy mistress was a gig he had to get done yesterday!

Ask yourself this:

Is there just one thing demonstrating good OOP or Design Patterns that I can do with this project?

Now that you have the handy Lunch Bucket Rules this shouldn’t be as much of a problem as before. Nobody, and I mean nobody is able to follow all of the OOP and design pattern rules all the time. However, being realistic, we need to start somewhere. Over time as we develop modules done using design patterns, we become more accustomed to doing it right. Let’s face it, at some point we gave up sequential programming in favor of procedural programming, but it didn’t happen all at once. Then, we gave up procedural programming for object oriented programming (OOP) and then started design patterns, and it’s not going to happen all at once either. However, if we don’t start someplace, it will never happen.

Take care,
Bill

For me it is really difficult to be observant of the right design especially if you are tied to short schedules. As a result I sometime find myself hoping that I could rewrite/redesign everything again though sadly there are always not enough time to recode.

Thanks for those kind words. I think that the most important discovery I made in this blog is that I’m in the same boat as everyone else as far as immersing myself in good OOP. (Sounds like being dipped in a tasty pudding.) That is, I know about the principles, but too often I’ll just put something together and worry about structure later. If things are really hectic, later never comes… Unfortunately, especially with smaller projects, everything works pretty well, and that’s why bad habits (mine!) are so hard to break. I almost wish that any program I wrote NOT following good OOP would explode like a big bomb, singe my eyebrows, set my hair on fire and make the dog howl. Then the bad habits would be easy to break.

Lacking such a handy reminder as exploding programs, I set about to put all of the main DP and OOP principles in one place and in the form of good habits (this and the previous two posts on principles) and ways to help remind us what the principles mean–The Lunch Bucket Rules.

Like all principles, rules or guidelines, the first step is getting them all down pat. Once they become part of a mindset, then you can begin to find exceptions. Right now, though, I’m trying to get them into a format where I can put them into an AIR application and have it handy. (See http://nemo.mwd.hartford.edu/~wsanders/lunchDP/ for the starting point–ideas welcomed!)

Thank you again for your insights,
Bill

agreed. I see, we’re on the same track. I guess, what i wanted to express was, by explaining the specific scenarios, in which inheritance makes sense (as you seem to have done in you book, sorry haven’t read it yet, will do so asap) and presenting those in contrast to the scenarios, in which it doesn’t make sense and principles like composition are more suitable, developers might understand the pros and cons better and will more likely choose it more wisely.

And to your first paragraph: I am aware, that you are quoting other people in your posts. But it would be boring, to simply read quotes on this blog. So what makes reading this blog interesting, is the combination of those quotes and your very own experience and the way, you look on those things. Otherwise, i could simply buy the book from the GoF (if i hadn’t already done so). So, go on, take the risk of expressing things in your own words, i’m sure, that’s what keeps people reading your stuff.

When I write a post about a principle you can assume that it is not my principle but rather one from OOP or design patterns. I agree with the principles, but I am certainly not their author. Most are from GoF but you will find others from different sources, such as Barbara Liskov. So when readers say to me, …your principles… or …you are saying… I feel uneasy. I’m not claiming to be just the messenger because I fully support these principles. Rather, I am hoping readers of this blog will think about these principles in terms of the very smart people who developed them and not some wild hair I concocted.

As you saw reading the entire post, the Gang of Four do not rule out using inheritance. Rather, they say that when you’re writing a program–and they’re thinking of big programs, not a simple gotoAndStop() one—you should think about it in terms of composition and not a hierarchy. Further, as you noted, the message is to keep the hierarchies shallow and the base classes abstract.

One of the best examples of where you can clearly see composition at work with inheritance is the Abstract Factory Pattern. There you will see all these little hierarchies with the Client holding a reference to abstract classes and composing a solution rather than relying on a single hierarchy. Thus, you have both programming to an interface instead of an implementation and and favoring composition over inheritance.

I’d like to agree with you and say if you’re really careful with hierarchies using private, protected and final access statements that everything will be dandy. I cannot say that. Rather, I’m saying we (not you, but we) need to evaluate how we use inheritance in our programs, and scale them back. Instead of adding another class or method, we need to consider adding another component to the framework to handle an added functionally.

When we do use hierarchies we need to consider design patterns that make use of them and examine exactly what’s going on. One of my favorite design patterns is the Template Method (Chapter 9 in our book). Your query is addressed in the section “Why Inheritance and Not Composition?” on page 335. It points out that there are indeed situations where inheritance is the way to go; so neither GoF nor we are dogmatic about inheritance.

However, let me hark back to the original point, favor composition over class inheritance. For the most part, it does say, don’t depend on inheritance to solve your programming problems. If you do, you’re likely to run into dependency problems, broken encapsulation, and a whole host of other problems.

Like everyone else who’s been programming for over 30 years, I like to think I know what I’m doing, but the fact of the matter is that I’ve had more time to build up some pretty bad habits. As programming languages change and evolve, as ActionScript 3.0 has, I need to re-think everything, and I have found that design patterns provide a way to kick me out of some of these habits. Favoring composition over class inheritance is a good habit I want to adopt, and it means that deep hierarchies need to be dumped.

Kindest regards,
Bill

i like the article. In the end, i think you’re not really proposing to NOT to use inheritance, but simply to avoid using deep inheritance hierarchies, which i totally agree with. You giving arguments for composition in favor of inheritance, but i would also like to see arguments for using inheritance and when it makes sense.

For example, building abstraction with types and subtypes is clearly something, you’ll want to use inheritance for. As Barbara Liskov stated, you should favor type inheritance over implementation inheritance and i think that nails it. If you want to make clear, that a specific type is related to a more general type, then inheritance is the way to go. If you are simply seeking for reusing as much code as possible, composition will be more suitable in many situations.

One last word to encapsulation within inheritance hierarchies. I would like to say, that inheritance does not automatically mean strong coupling. You can achieve quite some loose coupling between a super- and a subclass, if you use protected and private wisely as well as final. In that sense i see inheritance simply as another kind of association between two classes. You will always want to control visibility and encapsulation between classes and you should do so within inherited classes, too.