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
ReplyNext 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
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.
Reply1. 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
ReplyWith 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.
ReplyNext 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
ReplyWhen 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.
that is MFC.
ReplyYou 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
ReplyYou 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
ReplyNice 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 :-)
ReplyIn 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.
And many C++ programmers which produce complete rubbish too.
Reply"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
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.
ReplyDefinitely 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.
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