I believe OO design is more a perspective, a way of looking at things. Virtually all design methods have us decompose (break down) our problem into different things. Conventional design (structured programming) has us break our problem domain up into functions (modules that do specific tasks). That's why this is called functional decomposition. OO has us break things up into objects (object decomposition). But on what basis do we define our objects? The entities in our system (nouns for the objects, verbs for the methods) has significant problems. Abstracting out using commonality/variability analysis is much more effective.
The question then becomes, which is the best way to break down our problem domain into smaller pieces. I think OO design is better. Particularly when you have an OO language like Java to implement the design. It can still be done in non-oo languages, but it is harder.
Unfortunately, you can do non-oo programming in Java. I'd say more than half of the java code i see is of this type. In C++ it's even worse.
There is a broader question - how heavy is the OO methodology you use? Rational's Rational Unified Process is way to heavy for me. We're developing our own methodology we call Lightweight
Pattern Accelerated development that is based on XP but has a little bit more upfront design, uses UML for conceptual models and doesn't insist on paired programming (something we like but something not all departments will do).
How heavy you go has nothing to do with whether you are OO or not, it speaks more to the processes you like to follow.
------------------
Alan Shalloway,
Look for Jim Trott and my book:
Design Patterns Explained Visit our site
Net Objectives.
Visit our
on-line companion to the book