The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

You are here: The Pragmatic Craftsman > Better Coder

Go to: « Excellent CareerNews Newsletter | Teach Yourself Regular Expressions in 10 Minutes »

Special Exceptions Ruin OO Projects

In an object-oriented world, special exceptions are evil. To me, they ruin a well-structured framework/project. Yet in the business world, they are fairly common. What do you do?

I think the worse thing you can do is to actually add a special exception to a special-case free project. Once you do that, your project will take a downhill drive towards unmaintainability.

Let's say that you have a nice inheritance and polymorphism in place: a well-structured OO system. To be more specific, let's say you have a base class Shape and a Circle and a Square as subclasses. Everything works nicely: you only care about the Shape class and everything else takes its polymorphic runtime form.

Then, a business person comes in, with the usual time pressure, and asks you to implement something that resembles a Shape but it works a little differently. What do you do? You don't want to spend some extra time to refactor the original structure. And you don't want to implement a new structure as well -- too time consuming.

So what do you do? You add a special exception: you create a special-cased Shape. From now on, whenever you use the Shape object, you add the special exception to make sure something different is performed. Just a few lines of code. Everything works. You're happy. You're done. Quick.

But you did something else. You just ruined a well structured OO project. From now on, anytime you use the Shape object, you have to duplicate the special exception. It's only a matter of time when somebody forgets to do that. Ooops. A bug is let into the system. You created the opening with the special exception.

What else did you do? A level of frustration to the maintainer. The system is much more difficult to maintain after that.

Never do that! Take the time to do it right. Never put a special condition to a perfectly working OO system (with inheritance and polymporphism). Unless, of course, you don't care... and you consider yourself a crappy programmer.

I like the following saying: If you don't have the time to do it right, will you have the time to do it over?

You save some time at the time of implementation, but you will pay for it several times later.

So, anytime you need to add a special condition, and it's inevitable, refactor the code to support that, but don't add a special condition. It never works.

A better coder is a happy coder, don't spoil that. :-)


Comments

Post a comment









Remember personal info?







Go to:
   « previous entry: Excellent CareerNews Newsletter
   » next entry: Teach Yourself Regular Expressions in 10 Minutes

Random Quote

Search

 

Topics

Architecture & Design :12
Better Coder :29
Books :43
Books Recommended :18
Buzzwords :5
Career :25
Craftsmanship :15
Java :15
Quotes :25
Recommended :9
Software Engineering :3
Uncategorized :33
Web Development :1

Archive

May 2008 (1)
April 2008 (2)
March 2008 (1)
February 2008 (1)
January 2008 (2)
November 2007 (1)
October 2007 (3)
August 2007 (3)

...since January 2002

Currently Reading


:: See list of books I finished reading

Info

© 2001-2008 Stanley Kubasek About me :: Contact me