Listen, I’m NOT a OO snob or apologist, but when OO is done correctly, there’s nothing like it. When the pointy-haired boss comes by the cube farm with a bunch of new requirements, a well designed OO project can usually handle all the new stuff seamlessly.
The problem is designing an OO project is an incredibly difficult/complex thing to do.
And judging by the comments here, you’ve all run across some really bad OO code. Unfortunately, the language and/or methodology gets a bad rap when the people have a hard with it. It’s still up to the human; the best IDE, language, methodology, etc. will still allow you to cut off your fingers without warning. That and computer science courses in college aren’t teaching objects… the cover of the book may say so but after page 1’s “hello world”, there’s 500 lines of code in main().
I see a lot of myths from the functionally decomposed folks in the crowd:
- “I totally agree with your point, as I see OO being useful for larger and long term projects. My own hatred of OO overkill is when the objects are so badly designed they can’t possibly be extended.”
OO has nothing to scope nor schedule… furthermore, if the objects couldn’t be extended, then they aren’t really objects in the first place. The use of the new keyword in and of itself does not == object.
- “Some are just silly, like the Factory pattern, and truly are about working around an issue in the language (for example, the lack of classes as first class object in C++, where you could pass a reference to the Class object instead of a function pointer to the factory).”
That person is not writing OO code and the factory pattern is used incorrectly if you honestly think this.
- “you know, put some code here that we can jump to from a bunch of places, putting the return address over here”
A true OO project does not return values… the objects should know where to get it. Unfortunately, and I’m guilty of this, mutator/accessor methods have become pervasive and associated with OO code but that is the wrong way to do it. And yeah the language lets you do it but the language also has the “goto” keyword but I don’t seem anyone using that anymore.
- “Then again, objects are one reason programs get to be large scale: OOP code is bloated, especially in C++/Java/C#.”
Hardly OO’s or the language’s fault… sounds like a developer trying to write top-down code in an OO language. Well defined objects are hardly bloated.
- “I mean, jeez, how many times do you have to type the same old boilerplate public int Blah { get { return _blah; } set { _blah = value; } } ? Then there’s the endless stream of type declarations and casts – I mean, the functional languages like Haskell and Ocaml are smart enough to infer types, why can’t C-style languages do this?”
Because your example is NOT OO code… that’s very functionally written; the return type is a dead giveaway!!!
- “I had an “understanding” of OOP and could have probably passed a verbal interview’s worth of questions even. But, and this is sad in retrospect, it didn’t start clicking for me until Visual Studio .NET and I started enjoying much better intellisense in my IDE”
This is NOT a personal comment but the IDE does not make someone a better developer. If you’re in VS2005 and banging away on the dot or ctrl + space to see what interfaces and methods are available to your types, I betcha you’re still writing very procedural code.
Finally, and for goodness sake… don’t mix the two. When you mix procedural and OO, cohesion and encapsulation start to suffer very quickly.