I will tell you a story :))

I had a game which can show a large variety of duck species swimming and making quacking sounds. The initial designers of the system used standard OO techniques and created one Duck super class from which all other duck types inherit.

It looks good, right??

But in the last year, the company has been under increasing pressure from competitors. After a week-long brainstorming session, the company executives think it's time for a big innovation :vvv. They need something really impressive to show at the upcoming shareholders meeting in Hanoi next week.

Now we need the ducks to FLY. And of course my manager told them it'll be no problem for us to just whip something up in a week :))

I just need to add a fly() method in the Duck superclass and then all the ducks will inherit it. Genius!!!

But something went horribly wrong...

A shareholder told that they just saw a demo and there were rubber duckies flying around the screen :(( wtf !!!!

Because when I added new behavior to the Duck superclass, I was also adding behavior that was not appropriate for some Duck subclasses.

Okay, so there's a slight flaw in my design. What I thought was a great use of inheritance for the purpose of reuse has not turned out so well when it comes to maintenance.

I realized that inheritance probably was not the answer, because I just got a memo that says that the executives now want to update the product every six months (in ways they have not yet decided on). I knows the spec will keep changing and he'll be forced to look at and possibly override fly() and quack() for every new Duck subclass that's ever added to the program... forever!

So I need a cleaner way to have only some (not all) of the duck types fly or quack. I decided that take the fly() out of the Duck superclass and make a flyable() interface.

Thay way, only the ducks that are supposed to fly will implement that interface and have a fly() method... I also make a Quackable() too, since not all ducks can quack.

It's good, right??

Could you think about that? the dumbest idea I've come up with. If I thought having to override a few methods was bad, when I need to make a little change to the flying behavior... in all 50 of the flying Duck subclasses???

It solved part of the problem, but it completely destroys code reuse for those behaviors, and just creates a different maintenance nightmare!!!

And of course there might be more than one kind of fly behavior even among the ducks that do fly... Because I've been making a game, anything could happen.

And now I felt disappointed with those above solutions. And Design Patterns comes and saves the day.

Wouldn't it be dreamy if there were a way to build software so that when we need to change it, we could do so with the least possible impact on the existing code?

Yeaa we could spend less time reworking code and more making the program do cooler things...

Ohh! the post was quite long :))) Let's me show it in another post, haa :))

See you!!!