...comes from good up front information. The more you have, the better design decisions you'll be able to make.
There are plenty of good OO design tools out there. Unfortunately, to use them properly, you still have to have a pretty good comprehension of what you're developing, the components you're likely to use, what kinds of activities will happen to the product/programs you're creating, who will use it, and how.
It's time-consuming, but that IS the basis of OO development...you can't develop an OO system if you don't understand what the system is going to do and what kind of software toolkit you need to build as the framework for your app.
Unfortunately, in the twenty-some years that I've been working in the industry, I have yet to find many places that allow the proper time for proper design...especially OO design. It's a pity, really, because the amount of time and money spent fixing or redesigning the software after a project has already begun (or worse, finished) far outweighs the amount of time that would have been spent up front in the first place. Companies don't want to hear how "working" code can still be wrong and cost them money in the long run. They want you to do it right, but by the impossible schedules they dictate.
But enough ranting about that...
Best shortcut I can offer you is to try to abstract the common functionality from the pieces of the app you're trying to design.
A guy in our group wrote a really cool Java program that's designed to write SQL table create scripts for the three different database flavors we install to. Because the tables used the same columns, he built a huge single function around the process that retrieve the column info to use and scattered the write statements for each of the three types of scripts throughout the course of the function.
There are several better ways to have handled this, but the obvious common functionality...the process that retrieves the column info...along with other items like the output file management processing, belonged in a parent class, with the specific information needed to define the three different types of scripts being in their own, unique child classes.
The rule of thumb used to be that if you have to write the same piece of code functionality twice, it probably needs to be in a function or class of its own. That doesn't always work with OO design, but if you approach your design work with that thought in mind, it might help you identify a basic hierarchy of functionality in your app.
Figuring out what works and doesn't work in OO design takes time and isn't immediately obvious for a good part of the programmers out there. It's part of the reason that the OO revolution fizzled.
Be patient and keep at it. I know it's a pain to watch the folks who seem to assembly-line programs out with little care or ease, but it's been my experience that most of them are making the same mistakes that you're worried about making...they just don't care enough to try to design their work better.
Good luck! |
