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?
good point.
If the problem were later expanded to cover RAM amount, filesystem display, system time, etc., and there were a requirement for displaying all this on other than command line, then design pattersn would make sense. The trick is to catch/foresee the requirement creep at the right time, and switch to a more complex && flexible approach.
(BTW, for the OS detection, I'd use ANT - it has a native task for this (1 line!), and is platform-independent.)
KISS vs. Flexibility
I must agree, good point. Too often, I see systems that are overly complex because someone thought of built-in flexibility as the holy grail. Bloat alarm!
Following the "Keep it simple, stupid" principle, one always has code that is at least as understandable as the problem domain. If more flexibility is needed later on, the code is easy to refactor.
Solve the problem. Patterns will emerge by themselves. (Hey, that would make a great quote...)
Targets for Refactoring
In the GoF book the point is made that patterns provide useful targets for refactorings, as well as saying that using them early can prevent refactoring later on. It's obviously a question of balance.
The Java world is very susceptible to the overuse of patterns, partly because they're used so heavily in the standard library and partly because Java and patterns became popular at the same time. The result has been canonical architectures like those in J2EE where you often get database, persistence layer, business logic layer and presentation layer being proposed as the "right" way to go. That's fine if you're a Telco or a bank with lots of interworking systems, but for Joe Webcoder a simple tag library like JSTL was all you really needed in the first place.
It always seems to come back to "the simplest thing that could possibly work"...
Ian.
not using it ALL the time is OK?
"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."
Point well taken, but does this just apply to OO and patterns or can it also apply to other things such as code inspections, design, refactoring, and testing? For example, if code inspections are good, a naive person might assume that doing them ALL THE TIME is even better.
Taylor
not using it ALL the time is OK?
That's a really good question.
My initial reaction is to say, "No, it'd be silly not to design, refactor, test, and review as often as possible."
Of course, I write a lot of little throwaway programs that are simple enough that I don't feel guilty for not writing a formal test suite. That makes my first reaction seem pretty weak.
Perhaps there's a difference between tools -- functional programming, OO, data-driven programming, patterns -- and techniques? For example, using design patterns is part of design, but not all design has to use patterns.