The Pragmatic Craftsman :: Simplicity from complexity : by Stanley Kubasek ::

Special Exceptions

I’m working on a legacy project and I’m frustrated. It’s a mess. It seems that it was built to never be modified. It is just a pain to make even a small change to it.

I hate when I’m working on an Object-Oriented project and it contains special exceptions. C’mon, use polymorphism, use template methods, whatever, no special exceptions. I think what happens is that people design it nicely at first but then when a change is requested they just create a special exception because it is faster. Don’t fall into that trap. In essence, with that one exception they broke the system. The next change is “just another” exception. On and on… the system becomes a nightmare to modify for a new person on the project.

In any case, a system like that is slow to modify. You make changes to the system and you are scared that the roof will fall — problems appear in different places. That’s not object oriented programming, that’s hacking and destroying the system. So, next time you want to add a special exception to a fully working system, think twice, because, in essence, you are breaking the system. Put the time in and refactor it. Keep it object oriented and you will be glad that you did.

So how do you make your system better, more object-oriented? Keep it that way! Don’t break it by putting special exceptions. No exceptions. Really.

One of the rules that I have when working on any type of a change is to make the system better. Better for me, and better for someone after me. I always do that. Whether it is breaking it into a smaller method, creating a new class, renaming a method. Whatever works, whatever makes it better.

Favorite Quote




Currently Reading


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

Me on Twitter

»see more

Recent Entries