Updated: 7/26/2002

OTUG 1/15/2002 Meeting

First, I would like to thank the members of OTUG for their opinions and feedback. Even if we don't agree, we may still learn something from each other.

I would note that the polls taken of the participants do not offer very much information on why our opinions differ, other than confirm our differences. In my opinion such a meeting would be more fruitful if fewer topics were covered in more detail and depth. The most fruitful debates that I have been in come about when one issue or example is focused on and "beaten to death".

The rest of my comments are presented in the order of the meeting notes.

• Summary of the article was given (see-attached document) with the intent of discussing 3,7,9,11,15,20 in the Fishbowl Panel.

  I am not sure what document is being referred to here.

• There was a general consensus that the author of the article, although is specifically using the term OOP throughout the article, is using OOP interchangeably with Object Orientation (OO).

  I never find agreement on what definitions of OO, OOP, OOA, OOD, etc. are. If anybody has good, clear definitions, I would like to run them by comp.object (newsgroup) to see if there is a general consensus there. The meeting notes even later state: "Furthermore, it was acknowledged that even experts in the OO fields have not been able to come to a consensus of what exactly constitutes the OO Paradigm."

• Lack of training was determined as the leading cause of this confusion.

  Even (self-proclaimed) experts can't seem to agree on these questions. Training seems to have little to do with it. How can the experts train the "truth" if they don't have consistent opinions themselves? If it is an opinion, then it should be stated as such.

  Sometimes experts will claim that others experts who do not agree with them are not "trained properly". I have no easy way to solve these. They appear to be fundamental differences in philosophies rather than lack of knowledge based on my observations of comp.object debates.

• As far as application of OO principles in varying project sizes and industry types is concerned, one of the participant quoted Jacobson "OO applies in some situations better than the other " . This, the group agreed, is specifically true for industry types.

  That might be true, but there is no consensus on what industries. (Except for maybe CAD/CAM, see below.)

• [Protocol coupling] was strongly defended by OO enthusiasts present for this discussion. "Coupling leads to better understanding of relationships, provides for implementation hiding through API and increases reuse".

  I would like to see more evidence or demonstrations of this. I have since added a portion to my website titled Coupling Needed for Reuse?. Basically it says that you don't have to convolute the interface to use other protocols internally. In other words, reuse and exposure of coupling are not locked together.

• Several members still reserved the thought that the [database] mismatch might have been solved for CAD/CAM applications where OODBMSs are used extensively and rightly so, but general enterprise business apps still face that problem.

  I have heard similar suggestions that OODBMS's have worked well for CAD/CAM databases. I don't dispute that. However, CAD/CAM is outside my domain of criticism. But, for business applications, RDBMS seem here to stay for quite a while, and the "impedance mismatch" is a tax that must be accepted as part of the cost of OO.

• How [his criticism] relates to the OO Paradigm was still a confusion in everyone's mind. Nevertheless, applying good code and design practices like refactoring were discussed in the business-programming context. With an industry case study of approx. 5000 tables in a business application, the participants agreed that although iterations as part of the development are generally not bad, refactoring persistent data iteratively is a bad idea.

  I am not following this. Is it saying that OOP code refactoring is simpler than relational structure refactoring? Is it an anecdote about a system with 5000 tables? As far as specifics about those summary points listed, almost all are explained in more detail in examples on the same page or on links given on the same page. If the group wants to pick one of those topics to focus on at a time, I would happily guide them to the areas with more detail on them.

• Everyone in unison agreed that OO promotes and requires modeling the real world.

  This is curious, because on comp.object (newsgroup), it seems to be roughly 70 percent of OO fans against the notion that OO is about trying to model the "real world". (Even Bertrand Meyer does not seem to hold a real-world-model- heavy view). I don't know how to account for this apparently large difference between pro-OO groups.

• As part of this requirement, business knowledge is embedded in the system model. Since modeling is promoted, reuse factors in implicitly as part of system design.

  I am not sure how trying to fit the real world by itself promotes reuse. I see no connection between the two nor know of any "cliche examples" that promote this idea. Nor am I convinced OOP inherently better models the real world. Nouns often don't "self-handle" themselves in the real world.

• That "proper" behavior of classes or objects in a system should be ascertained in any paradigm and not just in OO was the prevalent thought. OOP should not be looked as carrying this extra burden, this should happen as a part of any paradigm being used for s/w development.

  This seems to contradict the prior "promotes and requires modeling the real world" statement.

• Finally, the group agreed that the OO models around nouns and not verbs. This [makes] the model more true and close to the real world as opposed to the procedural world where functional verbs are used for function/procedure naming convention.

  I don't see how nouns are more "real world" than verbs. Both need to be used in conjunction and appear to be roughly equal in importance in language. I have more to say about this at OOP Better Models Sentences?

  Perhaps OO fans think internally more around nouns. I cannot verify this. My working assumption/conclusion is that paradigm preference is probably subjective. IOW, OOP may better model the way OTUG members think. But, individuals and industry must be careful not to extrapolate this onto everybody else. Otherwise, people may get really upset and start writing anti-OO webpages.

ActionScript.com - The Case Against OOP

• After all, Flash is a very lightweight platform. Do OO techniques actually add value in a real-world context?

  I don't think size is really the issue. OOP does not better organize complexity in anything I have seen. (Perceptions of "better organized" can be very personal. Decent metrics are unfortunately lacking. Generally code-size and change-scenario-impact-analysis is used these days.)

• If we could organize our code better, by using OOP, we've already come a long way.

  That is a big "if". Show me an example of OOP being better organized. I hear about such Unicorns all the time, but never see them with my own eyes.

• I built all kinds of stuff to mimic named parameters behaviour as mentioned in the article. The fact that a language is OO, means you don't have too anymore.

  "Mimic"? Named parameters are not an invention of OOP. Perhaps your distaste for OOP is from using poor procedural languages. (Granted, there are fewer procedural choices because OOP hype is killing them off.)

• The memory usage of an OO based enviroment exceeds a procedural one

  I would note that my criticism generally does not focus on machine resources or performance. It focuses more on human factors, like the effort to make given changes.

• I personally am able to code faster, cleaner and more readable code using OOP techniques.

  I won't necessarily question this. It may all be subjective. However, the industry is assuming that OOP is objectively better and ignoring alternatives.

• Although the author does make some valid points I'd like to point out that he is also being very one sided

  So? There is much one-sided about pro-OO literature. If you have good evidence that OOP is better, I shall gladly link to it.

• By the way OOP isn't a law or dogma - it's just a simple think that human beings use since we build up our industrial world !

  This appears to be a variation of "OOP better models the way humans think". Humans think differently from each other. It may indeed better model your head, but please don't extrapolate that to everybody else.

• A procedural built product with this kind of flexibility would probably be bigger.

  Prove it with side-by-side code, Mister!

• Multiple (but similar) objects in a procedural program actually take up more memory than OO objects.

  Evidence?

• Procedural components over OO components, I don't think so. The whole basis of the components is to make then extensible. Using the components, you can not only change the colour, but also the entire skin. You can easily go from the basic skin to something that looks like the Mac OS X style. Which is much than colors, David :) [....] With out the components being so OO as they, means they can be extended. OO allows you to alter and perform actions on something, without ever knowing what the something is. This is a huge advantage, instead of building code for this, you can build OO code that works with this*10 or this*whateverNumberYouWant - as long they all have certain properties.

  This sounds like typical OOP "brochure talk". I would like to see actual code of this happening. Often the examples given after such a request suggest that the author is not a very good procedural programmer and/or using a crippled language or tool-set.

• Why use a complex and convoluted scripted solution when one involving simple actions and frame positions will do?

  I am not familiar with your particular language or domain. I don't know how your language handles procedural frames (or whatever they are), but just because that particular language gave you poor options does not mean that the fault is the paradigm itself. Don't throw the baby out with the bath-water.

  Even if by chance OOP is better at graphics scripting, that still does not make it better for all domains. State management restrictions may prevent use of relational tables in graphics scripting, so perhaps language-centric OOP structures may be the way to go. (Relational tables are a key to organizing complexity in my domain.) However, I would note even 64K CPM machines from the early 80's could fit reasonably sophisticated relational engines on them. I agree that there is a learning curve for proper use of relational techniques, but sometimes you have to bite the bullet if you want the power and flexibility. Easy-to-learn and easy-to-maintain are not necessarily the same thing.