I’m going to try and keep this post short, otherwise I’ll be here all day ranting away 
This particular topic is one that’s fairly close to my heart because it’s a bit of a pet hate for me.
As we (the geeks) know, object-oriented (OO) programming is a different concept to functional or procedural programming. OO was a bit of a move forward in the direction of easy to understand, more managable and reusable code, and has been adopted all over the shop.
One of the first widely adopted OO languages was C++ probably because of it’s close relationship and similar syntax to C. Unfortunately, this resulted in something that continues to be a huge bane for true OO programmers all over the planet: the OOPP (object-oriented procedural programmer).
OK, so that’s a term that I like to use when talking to this kind of programmer 
But the idea behind them is this: when they made the switch to C++ from C, they didn’t adopt a true OO approach to software development - all they really did was switch compilers. There are so many people still to this day writing software using OO languages without actually writing good/proper OO code. The benefits of OO are lost on these kinds of people, and the resulting code is just a nightmare.
Before my current job, I worked in a couple of places where there were a few stagnant coders writing C++ - but in fact it was just C being compiled with a C++ compiler. Coupling was through the roof. Encapsulation was non-existant. Even funky features such as polymorphism were avoided to be replaced instead by huge ’switch’ statements which did similar things based on the ‘type’ of a structure. Absolutely awful.
At the end of last year I worked with a lady who was by far the worst culprit for this. She was an advocate for “copy and paste coding”, structureless code and job security. She was appalling. How she’s managed to gain contracts for the last 13 years as a developer I will never know. It’s people like her that end up producing systems that are so unmaintainable, badly written and poorly executed that lots of people lose faith in software. She even managed to this in C#!
When are people going to learn that writing procedural code doesn’t make them an OO programmer? Using an OO language isn’t enough, you need to write code in an OO manner.
Before I make my final point I want to make it clear that I have nothing against C, or procedural programming. They both have their place. What I feel doesn’t have a place is a programmer who refuses to write OO code when that’s what they’re hired for.
So, to finish up, what I want to say is this: just because you’ve written procedural code in the past and it’s always worked for you, it doesn’t mean that you can continue to do it in an OO language when you’re paid to write proper OO software. If you can’t keep up with technology, proper methodology, and best practice, then perhaps it’s time to retire?
February 2, 2007
I agree, although OO has promised re-use and easier maintenance of code, I tend to find that unless appropriate refactors are made (that means unit tests being present before the refactor and unit test to mark the changes) OO can become a big pile of spaghetti code with “if” statements.
Have you guys ever looked at Spring? What do you think?
February 2, 2007
It most definitely can mate. I think it boils down to discipline. If the coder is good, then he/she is disciplined.
I have looked at Spring. That’s the AOP framework right?
February 3, 2007
I think there are those that can go too far with OO though.
For example, there are evangelists that I’ve met that basically think that the “private” keyword should be removed from OO languages altogether. This reasoning isn’t because they’re stupid and don’t understand the value of private member fields/methods etc., in fact they’re very good developers who have been overcome by a need to to OO-everything. Their reasoning is that - if you have a “private” method in a class, then that method is implementing behaviour that should be pushed out into a “public” member on a different class, EVEN if that ends up being the only code IN that new class.
With this kind of thinking, you end up with thousands of classes that each contain very little code, and whilst all very OO-proper, nicely decoupled and what not, it is again in fact a mountain of OO-spaghetti that the compiler can still understand quite easily, but that you as a good developer would be hard-pressed to make sense out of.
If you’re looking for a good example of this, just take a look at the code for the Microsoft Data Access Block. It’s great to “use” because it’s got everything you’d need to abstract your code away from the DB implementation, but try having a look at the boilerplate under the hood. I consider myself to be fairly proficient with ADO.Net code, hell we all had it coming out our ears before Microsoft decided on making the App Blocks, but this code takes abstraction to another level. They’ve got factories for factories, and builders for those factories. I have never seen a more complicated way of setting the connection string, but heck…it’s damn pretty OO!. Nuff said…
Going back to my first comment, I’d prefer not to - as an example - push the “file retrieval” private method code in my XmlManager class down to another XmlFileRetrieval class just so I can have everything public and, as some OO-practitioners would have you believe, have ALL behaviour exclusively attached to the proverbial hip of the “name” of a class. (Say that 3 times fast
) I’d prefer to have “some” well documented procedural code left behind to save me creating another file just to be an OO-purist.
In response to your article OJ, I do however agree with what you’re saying about developers who don the OO-hat but stick to their old ways because it’s what got the bills paid in the past, and I know you said procedural code has it’s place, but I’d like to venture that OO and procedural code can actually live together in harmony and that each has it’s benefits and drawbacks, and that strangely enough, most times, they can actually compliment each other if you know what you’re doing.
My two pence
February 4, 2007
That’s quite a large comment Rob
I think if we focus on the point of my article, and the point you made in your comment, we’re actually talking about the extremes.
We’re both talking about people who flat-out refuse to write well-structured and easy to use OO code. The difference is that I’m talking about those who refuse to move into an OO world and keep writing procedural code in a bad way, and you’re talking about the OO evangelist who needs 8 layers of abstraction with factory upon builder upon design patter even if it’s not necessary.
I think the crux of the point is that OO should be used enough to create something that makes sense and that is neither over nor under-engineered. There is a sweet spot in the middle that lots of people miss.