Related link: http://csis.pace.edu/~bergin/patterns/ppoop.html
Quick; write a small program that detects the user’s OS and prints a one-line report about it. Choose whichever language you prefer. Done? Good.
Give yourself ten points if it works on Windows systems and Unix systems. Give youself five more points if it detects Mac OS X as a separate OS. (Give yourself a pat on the back if it prefers Unix to Windows — there are no extra points here, but you’re clearly on the right track.)
How many design patterns did you use? None? Sorry, you fail….
Okay, so the article presents a stupid little example and then tries to explain object oriented design, design patterns, and maintainability by asking one of the most persistently silly questions in programming today: What if the problem changes in the future?.
Supposedly, that justifies taking a working (if naive) Java program and breaking it into no less than seven files as well as using the Factory and Singleton patterns. Oh, and there’s also separation of the display layer.
Sure, you may need to add a new operating system later. That may involve writing some code. Look at the code that adds the Mac OS X logic, though. It’s two-thirds the size of the original, naive attempt!
If you’d used a data-driven approach, maybe using a hash table, you’d likely be solving the next real problem by now.
Being a good programmer requires having a good set of tools. Object orientation and design patterns certainly qualify. Unlike the silly test above, though, you don’t lose points if you don’t use them all the time.
It’s far better to ask does this code solve the real problem? and is this code sufficiently factored and tested that I can change it when needed?. Remember, maintainability is as much about not having unnecessary code in the way as it is about having clean, well-designed code.
I could just be making a big deal out of a stupid example, but SEVEN classes? Does that seem like overkill to you?