This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.
Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.
Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?
Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.
That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.
Problem is, object-oriented programming is useful when it is applied on an as-needed basis.
Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.
So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.
There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.
WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.