OO Can't Ruin Businesses, but People Can
Blogging newcomer Marc Funaro made a provocative first post over the weekend with his entry How OO Almost Destroyed My Business. It has gotten a lot of comments, some supporting him, and some taking issue with his conclusions. I started to comment but decided it would be better to generate a secondary discussion rather than add onto the already long thread.
Marc says he picked up ColdFusion as a non-programmer, and had good success with it until fairly recently. With the movement toward object-oriented development that is happening in the ColdFusion world, he ran into trouble. He read some books, some blogs, and took a class on Java development. And he ended up overwhelming himself with unnecessary complexity in terms of frameworks, design patterns, and OO architecture. He sums up the result of doing this pretty nicely:
"The bottom line is, when you NEED to use some OO concept, YOU'LL KNOW. *That's* the time to start writing OO-style code, and only then... not everywhere else."
Which is pretty good advice. It's something that any knowledgeable proponent of OO will tell you. I'm sorry that it took him a good amount of time and frustration to reach that conclusion, but I'm glad he finally did.
Where he goes wrong, though, starts right in the title of his entry. OO can't ruin anything, but people making bad decisions absolutely can. And what Marc did was make some bad decisions, because he was new to OO, confused, and, as he says, "downloading one framework after another, piling them all into an application". This is like reading a book on construction, and then going out and trying to build the Taj Mahal when all that was needed was a garage.
Bad decisions don't mean a person is stupid or foolish. Smart people make bad decisions all the time (I'm not conceited enough to call myself a smart person, but I definitely have made some bad decisions). Usually, it's simply a lack of knowledge or experience, or a failure to understand the implications of the choices you're making. But even that is OK, because when someone makes a bad decision, it can still have a positive outcome if it results in learning something. OO does not equate to using a framework, and it does not require the application of every design pattern under the sun. It's simply a way to organize code, manage complexity, and accommodate change. Sometimes, that is best served by using a framework like ColdSpring or Spring. Sometimes, design patterns can offer solutions to encapsulate variations in a system and cope with change. One of the key things anyone using OO must understand is that there are pros and cons to every decision, and multiple solutions to a given problem. The only way to learn how to assess these trade offs is through experience.
The reality is that a lot of ColdFusion applications don't require a massive OO system to power them. Many of the small- or medium-sized applications don't need an n-tier architecture loaded with abstractions and design patterns. But that doesn't mean that some of the good ideas of OO, like encapsulation, can't be used with big benefits. One doesn't need to turn every query into an array of objects. Just creating well-defined interfaces to expose behavior to the rest of an application will get you a long way. Once something is encapsulated, it's much easier to change it later if you need to. It might be just a few CFCs to wrap up the bulk of the logic and hide the implementation. That might be all that will ever be needed. But if (and, more likely, when) things get more complex and it comes time to start adopting a broader set of OO principles, you'll be in a much better position to do so.
However, there is another reality that can't be denied: in the debate between procedural and OO development, OO has won. It won many years ago. ColdFusion is one of the few languages left that supports procedural development to a large degree. If you want to keep being a software developer, or ever want to move to a language like ActionScript, C#, Java, Groovy, or Ruby, you're going to have to know OO. That's just how it is. And as Marc points out, even within the CF world, OO is taking over, and the number of jobs available to people without OO experience are going to keep getting smaller and smaller. Some folks may not like this and may attempt to rebel against the trend, but you can't stop the tide. OO is not going away, in fact, it's only going to get ever more ubiquitous. So it's probably in your best interest to learn about it. One doesn't have to use it on every project, nor does one have to use it to create a complex, over-engineered mess. But experience is the best teacher, both in terms of learning OO and increasing your demand in the marketplace.
So, with respect to Marc, don't do what he did. Don't try to swallow the entire OO buffet in one bite. If you try, you'll fail. You'll get frustrated. And in that red haze, you'll probably miss the simple benefits of OO. Instead, learn what you can and take time to digest the information. Experiment with it, but don't get carried away. Apply what makes sense to you where you can, in small bits. Remember that the goal is to learn, but it is also to help you do what works for you and build applications that satisfy customers.
I suppose the bottom line is: Don't be afraid of OO. Be afraid of anyone who says that OO is the only way to build an application, and be just as afraid of anyone who blasts OO because they got carried away with it and got burned.



