Richard Mansfield wrote an opinion piece for DevX entitled OOP is Much Better in Theory Than in Practice. It got me wondering how any bright, rational person could make such an argument. So, I spent some time thinking about it, and this is what I concluded.
Consumers and Producers
Although I understand a combustion engine well enough to drive a car, I can’t build an engine or a car, or even drive well enough to race cars. I enjoy music and know a couple guitar chords, but I can’t play in a band or write a symphony. The ability to drive a car and listen to music makes me a consumer of cars and music, but I am not a producer of either.
This is the problem with OOP. Many people understand OOP well enough to use it, but they are trying to create it too. That’s when OOP becomes POO. A huge number of people who kind of get OOP are creating POO. Maybe what Mansfield meant is that if you know OOP well enough to qualify as a consumer, you should use objects created by OOP experts and build applications as best you can by filling in the blanks. This is the model that is attributed—fairly or unfairly—to VB programmers: They code events. The paradox is that a lot of VB applications still work today.
For the sake of argument, suppose that some programmers have recognized at some instinctual level that they know enough about OOP to use it and, as a result, build applications the best way they can.
Building Well-Architected Systems Is Hard
Finding a single class and implementing it is not that hard. Building an entire family of classes, defining their relationships, managing CRUD, and doing so all with custom objects is exceptionally hard. If you don’t know about patterns, refactoring, and UML, and you don’t actually have some experience successfully designing objects, building a well-architected object-oriented system is almost impossible.
This is what I got from Mansfield, accidentally. He suggested that because a huge percentage of projects fail, OOP must not be the great solution that it is purported to be. This is wrong. The real problem is that many, many programmers know OOP well enough to consume it but not well enough to produce it.
My theory of OOP consumers and OOP producers may explain why VB, FoxPro, RBase, and Access programmers feel successful: They are using the objects provided by expert OOP producers and finding a lot of success doing so, but they may not be trying to define whole families of classes. They are OOP consumers and not pretending to be producers.
Know Your Limitations
Faulty reasoning will lead one to believe that OOP isn’t good because a large percentage of OOP projects fail. The reason a lot of these projects fail is because talented OOP consumers are playing the role of OOP producers—they can drive cars on the highway, so they’re trying to race them on speedways. As Dirty Harry said in Magnum Force, “a man has got to know his limitations.”
I am not making an assertion about any programmer’s ability in particular. I am making an assertion about our industry as a whole, relative to OOP. A huge percentage of projects are over budget, over schedule, over promised, under delivered, or never delivered at all. Not all of these failures have to do with technology or OOP, but many of them do. I am also asserting that a measurable contributing factor is that many talented programmers are trained as OOP consumers, but their skills are not the same as those required to be OOP producers.
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his book Visual Basic .NET Power Coding from Addison-Wesley and his upcoming book UML DeMystified from McGraw-Hill/Osborne (Spring 2005). Paul is also the founder and chief architect for Software Conceptions, Inc, founded 1990. He is available to help design and build software worldwide. You may contact him for consulting opportunities or technology questions at [email protected].
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org.
Copyright © 2004 by Paul Kimmel. All Rights Reserved.