While good design principles and techniques interact with object oriented programming, neither understanding or use of OO techniques is necessary to understand and use good design principles, and vice versa.

Furthermore OO design has characteristic traps and pitfalls which have to be worked around, and I remain to be convinced that the best design for any complex system is always OO. Quite the contrary in fact. There are many possible ways to design complex systems, and OO is merely one of the available tools for doing so.

In short, I agree with dragonchild. When someone stands up and says, "OO is good. OO is great. Everyone should be using OO." I think, "That is someone who has a religious point of view, I wonder if they have ever really thought about what they are saying?"

It is certainly true that you have stated your position without the inclusion of any supporting evidence. Certainly if your concept of how to go about designing software starts and ends with making Class diagrams, then you have a lot to learn...

IMHO procedural design just doesn't scale up for big projects. It doesn't mean that it is impossible to write with C big projects .. but have you noticed that big project written in non-OO languages tend to emulate OO and actually use OO design?

What about those huge projects that use functional designs? Like, for example, someone wrote a large order-processing app in LISP. That wasn't OO ... it was functional.

Now, you're also making a gross generalization, which is that OO and procedural and functional (etc.) cannot work together. The best large projects tend to have OO and functional and procedural working together.

For example(!) - a GUI backend is OO, in that it allows for objects to be built, like various Message:: and Signal:: classes. YET(!), the actual event processor is designed functionally, in that it uses handlers to process what it receives.

Is that a bad design?

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Obviously you can design good software and follow design principles without OO. I am merely pointing out the fact that many formal Software Engineering techniques can not be used without OO.

If you were to study Software Engineering then OO software design would be a big chunk of what you get taught. As for buzz-words most CPAN modules are OO and we wear t-shirts at work and thus live in a collarless soceity.