When OOP Becomes POO

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 pkimmel@softconcepts.com.

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.



Comments

  • RAD fails. I don't care if your doing it procedurally or OOP model.

    Posted by ahoodin on 04/06/2005 07:31am

    Come on, don't blame OOP for projects that get tossed out the door so fast your eyes spin. The 90s spearheaded a series of software projects that are so terrible they require constant attention. Mainly VB, MFC, VFP and all the other RAD tools for creating a GUI out there. This article should be called RAD is CRAP not OOP is POO. It is possible to create good projects with these tools, but only with a decent software spec or solid understanding of the final product. ahoodin

    Reply
  • This is the worst load of crap ever.

    Posted by ahoodin on 04/05/2005 02:33pm

    Next well have C++ coders and VB Coders at eachothers throat. If you fail at OOP, you never learned it! If you went to school for it, or taught yourself, you did! Some folks didn't stop to learn other aspects of coding, and that is why coders fail. What is VB written in? Any answers guys? Somebody bite their own tail, just like this whole article. A dragon biting its own tail. ahoodin

    • If you think this is bad...

      Posted by dheath29 on 04/12/2005 08:07am

      Kimmel states early on that it is an opinion piece not necessarily a detailed, researched dissertation on why OOP fails. He happens to have stated his opinion very clearly and succinctly that jives with my person experience. I feel that your three points would be far more applicable to the Richard Mansfield article "OOP is Much Better in Theory Than in Practice" mentioned in Kimmel's article.

      Reply
    • I think the things coders fail at are:

      Posted by ahoodin on 04/11/2005 02:54pm

      1. I dislike the spirit in which it is written. 2. I dislike the lack of a professional approach. 3. I dislike the lack of evidence to back up claims. Making this article just another load of heresy. ahoodin

      Reply
    • Programming Object Oriented-ly (POO)

      Posted by dheath29 on 04/08/2005 02:36pm

      With the large number of replies to this article, something about it must rub you the wrong way yet you do seem to _get it_. You stated "If you fail at OOP, you never learned it." That is essentially the gist of his article, although he states that although you can use objects created by someone else doesn't necessarily mean that you can such objects yourself. Just because you can drive a car doesn't mean that you can build one. Also, programmer's can fail with any programming style: assembler, procedural or OOP: I'm sick and tired of trying to debug someone else's 3000+ line procedural C functions.

      Reply
    Reply
  • This is the worst load of crap ever.

    Posted by ahoodin on 04/05/2005 02:32pm

    Next well have C++ coders and VB Coders at eachothers throat. If you fail at OOP, you never learned it! If you went to school for it, or taught yourself, you did! Some folks didn't stop to learn other aspects of coding, and that is why coders fail. What is VB written in? Any answers guys? Somebody bite their own tail, just like this whole article. A dragon biting its own tail. ahoodin

    Reply
  • I believe in goo

    Posted by kd7gim on 04/05/2005 01:37pm

    When OOP becomes GOO, is because the developers did not understand their limitations. Essentially we are limited to handling data. Graphics are limited to graphs, charts, etc. Sorry, that is what computers do. Somewhere out there in the void is a new concept. I don't know if that is possible with OOP, but I am looking for it.

    • goo

      Posted by ahoodin on 04/05/2005 01:45pm

      that is MFC.

      Reply
    Reply
  • OOP doesn't fail. Coders doo.

    Posted by ahoodin on 04/05/2005 12:36pm

    You can write POO that is procedural too. Programmers used to fail at writing procedural code before there was oop. Now because there is such a thing as OOP you say OOP failed, Not the coder failing to code tightly. The OOP/POO theory is like string theory a bunch of nonsense. ahoodin

    Reply
  • OOP doesn't fail. Coders doo.

    Posted by ahoodin on 04/05/2005 12:20pm

    You can write POO that is procedural too. Programmers used to fail at writing procedural code before there was oop. Now because there is such a thing as OOP you say OOP failed, Not the coder failing to code tightly. The OOP/POO theory is like string theory a bunch of nonsense. ahoodin

    Reply
  • Asking for a light in a gunpowder factory? :-)

    Posted by Gabriel Fleseriu on 04/01/2005 05:13pm

    Nice article -- "food for thought", as someone else commented. I have to agree, if you don't know OOP well enough you can mess it up badly. What I don't like so much is some of the implications that your article seems to have: "Building Well-Architected Systems Is Hard", "Know Your Limitations"...it's like saying "give it up people, you'll never do it right anyway". Even if this were true and most programmers won't get it right, simply telling them so is not much of a help. Telling how to prevent OOP from going POO is much more helpful, IMHO. Along the same lines, you talk about "expert OOP producers". These people aren't born like that, you know. They are trained. As for the title (of my comment): discussions about OOP vs. anything tend to be explozive :-)

    Reply
  • The Language

    Posted by NoHero on 04/01/2005 06:12am

    In mey eyes the understanding of OOP and to be a so called producer of OOP does not depend on your language. So I think there are also many VB programmers who can "produce" perfectly large OOP systems by using design patterns and UML.

    • Yes and

      Posted by darwen on 04/03/2005 04:41pm

      And many C++ programmers which produce complete rubbish too.

      Reply
    Reply
  • I disagree -- sadly, OOP is always pursued by POO.

    Posted by Clugston on 04/01/2005 12:45am

    "The real problem is that many, many programmers know OOP well enough to consume it but not well enough to produce it." I don't quite agree. Of course you're right about the producer/consumer thing, but I think there is a genuine problem: OOP is _incredibly_ difficult to do correctly. Compare it with procedural programming, by far the most successful programming paradigm. It is very easy to write a top-quality function to be used in a procedural program. Unfortunately, once programs get too big, procedural programming starts to break down. Procedural programming was better than its predecessor, spaghetti code, in every respect. But this is NOT true of OOP. Why not? To some extent, I think it is because software architecture is an intrinsically difficult problem. But I do think that OOP itself must take a lot of the blame. In particular, I think that there is something horribly wrong with the concept of inheritance. You know what the primary rule in the GoF Design Patterns book is? "Prefer encapsulation to inheritance." And yet, almost all of the support for OOP in OO languages is for inheritance! Virtual/overridden functions, protected members, etc. And, "If you're not using polymorphism, you're not using OOP!" (Bruce Eckel, in his excellent C++ book). You can't use polymorphism without using inheritance. Contradiction! Therefore OO languages do not promote good designs. QED. Case in point: The Windows API was quite well-designed. But MFC, with its horrible document-view architecture, resulted in a whole generation of poorly designed programs. Can you really claim that the MFC team were novices? I personally have hardly ever been able to create truly reusable, non-trivial OOP classes. In my experience, only base classes can be reused. But I have had great success with procedural programming, and with generic programming. The problem with Mansfield's article is that he concludes that procedural programming was much better, and he even advocates copy-n-paste (!!!!) I was saddened by that, because on of Mansfield's books, "Compute!s first book of machine language for the Commodore 64", was one of my favourite programming books in the early 80's. It's interesting to me that C++ has moved away from OOP towards generic code, at the same time that VB has been manhandled into OOP. Anyway, your article was certainly food for thought, and the title is great! I enjoyed it. -Don

    • agreed

      Posted by ahoodin on 04/05/2005 01:48pm

      Certain VB programmers are just mad they weren't in on the whole OOP thing to begin with. They are just hating OOP because they don't know it. Now they have to do it, but it may be cludgy because it is VB.

      Reply
    Reply
  • word!

    Posted by andyf4i on 03/31/2005 03:20pm

    Definitely some strong points, but there is more. Consumers, from time to time, need to understand the intricacies of the objects that they use. Sometimes they just don't understand, which isn't so bad because they can ask and learn. Others don't want to understand; I affectionately call this class of people "worker bees". Worker bees want to be told what to do and how to do it and the only creativity that they express is in jury rigging software components (which is usually a step backwards). Managers need to beware of these worker bees; they have no business in ours or any technical or creative process. They chew up essentially equivalent salaries to the rest of us and their principal accomplishments are to kill projects...often in the name of "process" or "requirements"; these are not evil words mind you but they are meant to help, not hinder projects. So you can probably extend "consumers" with more detailed classes such as "useless consumers" and "productive consumers" and "apprentice consumers" (who want to be producers someday) and "worker bees" (who consume projects rather than code). Fortunately or unfortunately there doesn't seem to be a pre-determined series of steps that always leads to effective OOP, and perhaps effective OOP is financially infeasible on some projects. But every project has a mix of people with different backgrounds and sometimes agendas. Rather than just complain about these struggles I would like to offer my two cents worth: project managers should make sure every team member shares a complete and common vision for the project, also make sure people are in the correct roles, and every programming decision should be made with the following question in mind: what is best for the project? Maybe projects would benefit more if managers encouraged subordinates to read Sun-Tzu rather than software engineering and process management books. Many of the "focus" concepts in Art of War apply to software projects.

    • I like worker bees

      Posted by darwen on 03/31/2005 03:41pm

      Worker bees tend to be shifted onto testing pronto in our company... and fulfil a useful role in such. It's better than sacking them.

      Reply
    Reply
  • Loading, Please Wait ...

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: April 22, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Database professionals — whether developers or DBAs — can often save valuable time by learning to get the most from their new or existing productivity tools. Whether you're responsible for managing database projects, performing database health checks and reporting, analyzing code, or measuring software engineering metrics, it's likely you're not taking advantage of some of the lesser-known features of Toad from Dell. Attend this live …

  • Hurricane Sandy was one of the most destructive natural disasters that the United States has ever experienced. Read this success story to learn how Datto protected its partners and their customers with proactive business continuity planning, heroic employee efforts, and the right mix of technology and support. With storm surges over 12 feet, winds that exceeded 90 mph, and a diameter spanning more than 900 miles, Sandy resulted in power outages to approximately 7.5 million people, and caused an estimated $50 …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds