OOP considered harmful (was: C. Date on UML book)

[Ilja Preuss]

Originally posted by Thomas Paul:
I have lots of code that I know I can improve. But it's already gone to QA and if I make a change now it will cost thousands of dollars to retest it.

Yes, now it is to late. IMHO you should have refactored much earlier - because IME that would have speeded you up, not slowed you down. Refactoring shouldn't be something that you schedule, but that you do as your daily job, minute by minute.

[Ilja Preuss]

Originally posted by Thomas Paul:
The code is "perfect" when it (in order of priority):
1. does all the customer asked for (runs all the tests, if you are doing full XP)
2. contains no duplicated code
3. expresses all the ideas that need to be expressed
4. has minimal number of classes and methods

[...] That being said, 2, 3, and 4 are all elements that we work on given the restraints of time and budget. If we have to sacrifice something (and I have never worked on a system where I had unlimited time and money) then 2, 3, and 4 are where we make sacrifices. At some point we say that it is good enough and move on to the next project.

I stick to it: you get fastest by not sacrificing quality at all.
http://c2.com/cgi/wiki?QualityIsFree

[Thomas Paul]

Originally posted by Ilja Preuss:
Yes, now it is to late. IMHO you should have refactored much earlier - because IME that would have speeded you up, not slowed you down. Refactoring shouldn't be something that you schedule, but that you do as your daily job, minute by minute.

Just a quick comment: please stop using abbreviations like IMHO and IME. I have no idea what they mean and find them extremely annoying.
As to your comment, I don't think you have a clue what I am talking about. Do you only refactor programs or do you refactor applications? Do you work on all your applications by yourself? When 5 developers are required to put up an application in 10 days, do you refactor the entire application over and over again during development? If so, how do you ever produce anything? I get the impression that you work alone with little in the way of time constraints. You comment makes no sense if you are developing a large application under tight constraints. You can't go back to refactor pieces that have been moved on to QA because you now see that you have some reusable code that you should have taken advantage of earlier.

[Thomas Paul]

Originally posted by Ilja Preuss:

I stick to it: you get fastest by not sacrificing quality at all.
http://c2.com/cgi/wiki?QualityIsFree

Quality is only free in the long term. If you get fired because your app was three days late then it wasn't exactly free, was it, no matter how high the quality.

[Thomas Paul]

I think the link you provided has a very important comment: "I think you pay for quality up front, but it's an investment that pays off -- in the same way that a $50 Estwing hammer is initially more expensive that a $10 K-Mart hammer, but cheaper in the long run."
That only makes sense if you have $50. If you only have $10 then the K-Mart hammer is the proper investment, isn't it? As programmers working for a business trying to make money we must be very careful about how we spend that money.

[Ilja Preuss]

Originally posted by Mapraputa Is:
[QB]Uncle Bob wrote: "And even those things are result of the yin and the yang in proper combination"
If to think further, what is the one single idea behind those two? Orthogonality! They are orthogonal! Otherwise there would not be "yin and yang" and would be only one yin-yang.

They aren't orthogonal at all - they are two sides of the same thing. One couldn't exist without the other. If you take a close look, you will even discover that every yin contains a little bit of yang and the other way around. http://asiarecipe.com/yinyang.html

BTW, who said that in OO "*everything* is an object"?
OMG-2. You are not saying that it was me, are you? :roll: I quoted the expression to say that this is a bad idea and now my words were taken out of context!

Yes, but I thought you were criticizing OOP, so I implied that you thought this is a true statement about OOP.

Again, I suspect that it is rather hard to speculate about the balance between inheritance and composition without having experienced it...
It's like to say that in order to understand processes that happen during thunder storm, you need to be stroked by a lightning!

Perfect example! Benjamin Franklin (and his son William) didn't find out about the nature of lightnings by pure reasoning, but by going out into the storm!

[Ilja Preuss]

Originally posted by Thomas Paul:
I think the link you provided has a very important comment: "I think you pay for quality up front, but it's an investment that pays off -- in the same way that a $50 Estwing hammer is initially more expensive that a $10 K-Mart hammer, but cheaper in the long run."
That only makes sense if you have $50. If you only have $10 then the K-Mart hammer is the proper investment, isn't it? As programmers working for a business trying to make money we must be very careful about how we spend that money.

The refactorings I am talking about are mostly in the dimension of minutes and pay back after hours.
So, yes, sometimes I defer a refactoring for a day if something has to be ready today. Sometimes even that bites back.

[Ilja Preuss]

Originally posted by Thomas Paul:
Just a quick comment: please stop using abbreviations like IMHO and IME. I have no idea what they mean and find them extremely annoying.

You can look them up at http://www.ucc.ie/acronyms/ - they are rather easy to learn and you will find them everywhere on the net, so I think that would pay back. I will try to explain the ones I use in this thread, but often I don't even notice that I use them, so please forgive me if I miss some.
IM(H)O - In My (Humble) Opinion
IME - In My Experience (mhh, that one isn't in the database...)

As to your comment, I don't think you have a clue what I am talking about. Do you only refactor programs or do you refactor applications? Do you work on all your applications by yourself? When 5 developers are required to put up an application in 10 days, do you refactor the entire application over and over again during development?

No, I refactor only the code I am currently working on, but there I do it mercilessly. I do this when I am working alone as well as when working in a team.

[Thomas Paul]

Originally posted by Ilja Preuss:

No, I refactor only the code I am currently working on, but there I do it mercilessly. I do this when I am working alone as well as when working in a team.

That explains the problem between us. I'm talking about refactoring an application. And in OOP terms, the biggest rewards come from application wide use of OOP techniques.

[Thomas Paul]

Originally posted by Ilja Preuss:
You can look them up at http://www.ucc.ie/acronyms/ - they are rather easy to learn and you will find them everywhere on the net, so I think that would pay back. I will try to explain the ones I use in this thread, but often I don't even notice that I use them, so please forgive me if I miss some.

We have discussions about using abbreviations on JavaRanch. Here is a typical conversation:
https://coderanch.com/t/1143/Ranch-Office/There-ought-rule-against

[Frank Carver]

Ilja wrote: For me, "good enough" is implying that I can reach a state where I no longer have to think about improving the quality of the code - why should I do if it already is good enough?
Ah, I think I get it. Are you thinking of "good enough" as a static (to use my terms from several posts ago) status? Do you think of it in terms of "this code is now 'good enough'. Let's ship it and never look at it again"?
I view "good enough" as an essentially dynamic status, which is why I haven't understood your distinctions based on "why" you stop coding. Perhaps I should more explicitly say "good enough for now" or "good enough for these requirements" or "good enough until I know more". Of course what is "good enough" will change tomorrow, as new requirements or new insspiration comes in.
It also seems to imply to me that you could say something like "the code would be even better if we did XYZ, but it is already 'good enough', so we don't have to do it". Probably sometimes I fall into this trap, but it isn't something I would advise.
This also worries me. I am very wary of trying to somehow be "better" than "good enough". Which aspects of the development process (customer requirements? timescales? your own health and family life?) are you willing to sacrifice to improve other aspects of something beyond what is required today. How do you know that the project won't be cancelled (or radically changed) tomorrow morning ? Would the customer payng the bills prefer that you made one feature "better than good enough", or that you implement two features "good enough"?
Most importantly, how do you know that what you are proposing is really "better"? By surpassing "good enough" you have gone beyond the requirements and the tests, you are adding something no one has asked for and which may acvtually be something they implicitly don't want!
Or am I missing your point?
Can you give us a real, concrete, example of something which you consider "good enough" and what you would do to make it "better" ?
I have found huge value in a "test driven" approach to software development. So much so, that I actively seek out some sort of test or acceptance criterion for everything I embark on. Sometimes it's hard to pin down, for example with refactoring, which is why I like to divide the process into such small steps that I know how to be sure I have completed each one.
I feel that I have somehow let myself down if I embark on a task for which I won't know when I'm done. I also find it hard to be motivated at such tasks - you may remember some discussion here about tests for documentation.

[Ilja Preuss]

Uhh, just realized that my response to this post didn't make it to the forum - so I will try again.
This will also contain the Banner-example I referred to in an earlier post... :roll:

Originally posted by Mapraputa Is:
I disagree. The conclusion would be correct if you had to stick with the patterns you decided upon upfront. But you don't - well designed and -tested OO systems are rather easy to refactor.
I would only note here that probably any well designed system is rather easy to refactor and easy of refactoring is pretty much orthogonal to OOP...

Possibly. OTOH, there are refactorings which are nearly impossible in Java, but a matter of course in Smalltalk, so I wonder wether the paradigm could make a difference, too...

Later the book shows that "the preplanning problem" doesn't exist in Smalltalk because of its wonderful reflection system.
I don't get this - could you elaborate?
They call it "noninvasive, dynamic composition based on intercepting messages". As far as I understood, it means you can dynamically attach objects to other objects at run-time, while the code is untouched. You really do not need up-front design for it.

OK. I agree to the point that Smalltalk certainly is more flexible than Java.

And nevertheless there are many people (including me) who find the abstractions of OOP to be very helpfull for writing good software. I wonder wether there might be a fourth category missing...
Rats, I wanted to leave the fourth undefined category for extensibility and forgot Bad design. So what do you think, it is? Anything
that proved to be useful in practice?

Well, that is the best I could come up with till now...

I am confused - I think this is exactly what "extends" is doing: implicitely forwarding all calls to inherited methods to the super class.
Not "exactly". With how inheritance is implemented now, if a superclass added a method, a subclass will get it without recompilation. If we re-define "extends" to provide explicit method calls at the code level, the automatic inheritance of new methods will be prevented.

So wether the behaviour of the subclass changes would depend on wether I recompile it, too? Wouldn't that be very impractical???

The responsibility of a DOM parser is to parse XML - nothing more. It shouldn't have to know anything about Javascript. So, here delegation certainly would be the proper solution.
Then what would be an example of "is a" concept?

Here comes the Banner example - a real world example, if I didn't already mention it:
Let's say we are developing dynamic banners for a website. The different banners differ in content, that is the form of the generated html, and have some code in common, like forwarding a click-through. So we put the common code into an abstract baseclass and derive two concrete subclasses:
Banner
+ImageBanner
+HtmlTextBanner

Isn't it what specialization is about - to add extra services a base class doesn't provide?

IME it is the other way around most of the time: you put common code of two classes into a common base class.

Because, in the above example, we don't know how many customers the system will have to handle.
I did not understand that... How many customers - isn’t it orthogonal to the task of parsing? Or you are talking about another example?

Yes, I was talking about my example: "A state of anything the system is about - the state of a customer, for example."

Yes, it does, as we neither refer to interfaces or classes any longer, but only to the methods we expect an object to have.
Ah, I see. I mentally already got rid of instances and was left only with classes and interfaces.

Oh, sorry. Replace "an object" by "a class". For me, it doesn't make a difference, because in OO, *everything* is an object, even classes...

if we do not have inheritance,
SomeObject.someMethod(...) is the same as someMethod(pointer to SomeObject's data, ...)?

Yes. In fact, if "SomeObject's data" included jump tables to tell which actual methods to call when working on this object, you would have already implemented OO-like polymorphism.
If you then write a macro that makes it possible to automate the tedious work of defining the jump tables, you would have just implemented yet another OO language...

[Ilja Preuss]

Originally posted by Frank Carver:
[QB]Ilja wrote: For me, "good enough" is implying that I can reach a state where I no longer have to think about improving the quality of the code - why should I do if it already is good enough?
Ah, I think I get it.

Well, at least partly, yes!

Which aspects of the development process (customer requirements? timescales? your own health and family life?) are you willing to sacrifice to improve other aspects of something beyond what is required today.

I think what is required today is the best possibly code for the functionality implemented today. And I didn't have to sacrifice anything but bad code for it until now, as far as I can tell.

How do you know that the project won't be cancelled (or radically changed) tomorrow morning ?

I don't know wether the project will get cancelled tomorrow, but fortunately most of the days my projects don't get cancelled, so I think that is also the way to bet for tomorrow...
If it will get *radically changed* I will in fact need the most flexible code I can get, so it seems to me...

Would the customer payng the bills prefer that you made one feature "better than good enough", or that you implement two features "good enough"?

I think he would prefer me to implement as many features as possible in a given time frame. I do this by holding the code clean all the time.

Most importantly, how do you know that what you are proposing is really "better"? By surpassing "good enough" you have gone beyond the requirements and the tests, you are adding something no one has asked for and which may acvtually be something they implicitly don't want!

I am talking about refactoring here: changing the code without changing the functionality. I am not promoting "gold plating", far from!

Or am I missing your point?

Somehow, it seems to me...

Can you give us a real, concrete, example of something which you consider "good enough" and what you would do to make it "better" ?

Mhh, now that you ask - I really don't know how to tell wether code would be good enough, other than by not knowing how to improve it further...
Can *you* give an example of code that is "good enough for now", but you know could be improved?

I feel that I have somehow let myself down if I embark on a task for which I won't know when I'm done. I also find it hard to be motivated at such tasks - you may remember some discussion here about tests for documentation.

Yes, I know what you mean.
But do you also need a test for when a *project* is finished, or could you live with a forever ongoing project, implementing feature after feature?
That is how I feel about refactoring: one refactoring is rather short and I can tell when it is finished. But the process of improving the code never has to end...

[Ilja Preuss]

Originally posted by Thomas Paul:

That explains the problem between us. I'm talking about refactoring an application. And in OOP terms, the biggest rewards come from application wide use of OOP techniques.

I don't have any clue what you are talking about...
The refactorings I know are done in very small steps, so refactoring a big application would mean to apply myriads of small refactorings to part after part of it.
How does that connect?

[Thomas Paul]

Originally posted by Ilja Preuss:

I don't have any clue what you are talking about...
The refactorings I know are done in very small steps, so refactoring a big application would mean to apply myriads of small refactorings to part after part of it.
How does that connect?

Imagine you have an application with 20 classes. You know that inside those classes are large blocks of code repeated several times across multiple programs. Each program is very well written but you have still created a maintenance nightmare. One small business rule change could force multiple changes across many program each needing to be tested. We refactor the application by yanking out blocks of reusable code and creating separate classes. Now only a single class of shared code contains changeable business rules.
Personally I would rather work on a well structured application with classes that need to be refactored than on a poorly designed application with beautifully written individual classes. The odds are that the latter is going to be much more work to fix than the former.

[Frank Carver]

Ilja wrote: Can *you* give an example of code that is "good enough for now", but you know could be improved?
Ah, I'm ahead of you there. I make several comments to that effect in my refactoring examples, collected in this thread.
[ August 28, 2002: Message edited by: Frank Carver ]

[Mapraputa Is]

Originally posted by Thomas Paul:
I'm talking about refactoring an application. And in OOP terms, the biggest rewards come from application wide use of OOP techniques.

Tom! Now if you could exoplain briefly what the biggest rewards are? What does OOP brings compared to well-defined non-OOP application?
By the way, this thread was about 60 posts yesterday and today it is 95!
[ August 28, 2002: Message edited by: Mapraputa Is ]

[Thomas Paul]

Reusability and ease of maintenance. What did you think the rewards of a well designed OO application was?

[Ilja Preuss]

Originally posted by Frank Carver:
Ilja wrote: Can *you* give an example of code that is "good enough for now", but you know could be improved?
Ah, I'm ahead of you there. I make several comments to that effect in my refactoring examples, collected in this thread.

Mhh, in all those threads you seem to stimulate to original poster to think of further refactorings, so I did imply that in a real world you wouldn't stop there. Were I wrong?
BTW, the third refactoring example was most interesting, as I would have done it quite differently. Perhaps I will find some time at the weekend to post an alternative solution...

[Ilja Preuss]

Originally posted by Thomas Paul:
Imagine you have an application with 20 classes. You know that inside those classes are large blocks of code repeated several times across multiple programs. Each program is very well written but you have still created a maintenance nightmare.

Well, for me a well written program doesn't contain large blocks of code at all, but is composed by lots of little pieces.
I am not entirely sure that I understand your usage of the terms "program" and "application" correctly, though - you might even use "program" and "class" as synonyms???

One small business rule change could force multiple changes across many program each needing to be tested. We refactor the application by yanking out blocks of reusable code and creating separate classes. Now only a single class of shared code contains changeable business rules.

If the programs already were well designed, you probably only had to move one class from one program to the common code base and use that class in all the other programs. Ideally you do that when while working on the second program that needs the same logic, you (and I mean you, the team) remember that it is already implemented in the first.

Personally I would rather work on a well structured application with classes that need to be refactored than on a poorly designed application with beautifully written individual classes. The odds are that the latter is going to be much more work to fix than the former.[/QB]

So are you saying that it is less work to implement a poorly designed class than it is to implement a well designed class???
[ August 29, 2002: Message edited by: Ilja Preuss ]

[Thomas Paul]

Originally posted by Ilja Preuss:
So are you saying that it is less work to implement a poorly designed class than it is to implement a well designed class???

It depends on whether you are working on the class or the application, doesn't it? The point is that it is usually easier to refactor a class than it is to refactor an application.
That's 100 posts on this topic which is probably more than enough.
[ August 29, 2002: Message edited by: Thomas Paul ]

[Ilja Preuss]

Originally posted by Thomas Paul:
It depends on whether you are working on the class or the application, doesn't it? The point is that it is usually easier to refactor a class than it is to refactor an application.

How do you work on an application without working on the classes it is composed of???

That's 100 posts on this topic which is probably more than enough.

Well, not enough for me to get your point - but I understand that that possibly isn't a widely accepted measure...

[Mapraputa Is]

I found explanations that sound reasonable. Here.
I remember I found the site a year ago, but then did not read the whole text, only beginning and decided the author was in a bad mood when writing this, so it isn't worth reading. Maybe I am in bad mood now

[Ilja Preuss]

Originally posted by Mapraputa Is:
I found explanations that sound reasonable. Here.
I remember I found the site a year ago, but then did not read the whole text, only beginning and decided the author was in a bad mood when writing this, so it isn't worth reading. Maybe I am in bad mood now

He wasn't simply in a bad mood. He is known to the comp.object newsgroup as Topmind, and (was?) debating there for years using the same arguments time and again.
He is certainly right that OOP is not a panacea and that every developer should also know other paradigms. Besides that, I find his polemic pamphlet to be full of misunderstandings and bold assertions.
[ August 30, 2002: Message edited by: Ilja Preuss ]

[Mapraputa Is]

I guess, some people aren't created for Object Orientation. Either that, or my early exposition to the Table Orientation undermined my intellectual abilities. In any case, the text above makes much more sense to me than all I read about OOP.
Also, when you are saying "Isn't it a well known fact that even the average heads don't become teachers because those don't get paid enough?" - I am afraid you may be in trouble with many of our ranchers, Thomas Paul for one example.

[Ilja Preuss]

Originally posted by Mapraputa Is:
Also, when you are saying "Isn't it a well known fact that even the average heads don't become teachers because those don't get paid enough?" - I am afraid you may be in trouble with many of our ranchers, Thomas Paul for one example.

Oh, sorry, of course I was exaggerating.
I once had a genius as physics teacher - he simply wasn't there for the money, but because he liked to teach. If you are lucky, you certainly can find a good teacher (such as Thomas Paul, I assume); all I wanted to say is that you shouldn't be surprised if you find plentiful of not so good ones...

[Ilja Preuss]

Originally posted by Mapraputa Is:
I guess, some people aren't created for Object Orientation.

I don't think so. Nobody is "created for OO" - everybody has to learn it.

Either that, or my early exposition to the Table Orientation undermined my intellectual abilities.

(Warning: risky speculations ahead...)
No, but it probably formed your thought structures in a way that is incompatible with OO. What is probably hindering you is that you always try to compare what you learn about OOP to the relational way. You hear a detail about OOP, try to interpret it in the relational world and come to the conclusion that it doesn't make sense. You don't know that it does make sense in the OO world, because you are not familiar with it.
If this were true - would it suggest us a way you possibly *could* learn OOP?

In any case, the text above makes much more sense to me than all I read about OOP.

What parts did the most sense to you?

[Mapraputa Is]

What is probably hindering you is that you always try to compare what you learn about OOP to the relational way.
What's hindering me most is that I see the Solution, but I do not see the Problem this Solution is for.
What I observe is that what was simple with my old set of tools, with OOP getting unnecessarily complicated. You are saying: OOP is good for quick prototyping. Isn't it what scripting languages are for? Jython, for that matter... We worked with Clarion - template-based code generation engine. It was damn fast to develop a full-blown application, a lot of typical tasks were "encapsulated" in templates and if you need to adjust something - there are a lot of places you can plug in your code. It was easy to use, and what's better, templates were written for many languages, maybe even for Java (we didn't use it that time), so your application can be generated in any language you want. If there is no template - write your own. I guess, the same methoda wouldn't work if we were to computerize a giant enterprise, but we were not.
Another thing, it's hard to make estimations, but roughly 30-50% of my time was devoted to "write once and throw away" code. Endless data format conversions, data mining, etc. I really do not need all complexity of OOP for that :roll: The code was written "from scratch", nothing to "inherit" from, and nothing to "demise".
You are saying: "OOP abstractions are useful". No doubt they are useful. Look at this post in our XML forum (I know I should have barked at Melissa78, oh well... next time). Who will say the first solution isn't useful? Of course, it is. It's just that the second is much simpler and more elegant. There is another subtle difference, not clear from the code. XML is "Extensible Markup Language", in theory anyway. In practice, its extensibility is guaranteed by nothing, it's just a good suggestion in the best case (buzzword in the worst). You need to design your application in a special way for it to work with "extensible" XML. It was said on XML-DEV list that 70% of current XML applications would be broken, were some tag added. One of participants said he suggest to use XSLT instead of parsing with DOM/SAX (OOP) because it is so much easier to achieve extensibility.
You hear a detail about OOP, try to interpret it in the relational world and come to the conclusion that it doesn't make sense. You don't know that it does make sense in the OO world, because you are not familiar with it.
Let's see, I got "A" and "A+" in my college classes, I got my SCJP with 94% (it's not "developer" yet something), I read Grady Booch "Object-Oriented Analysis and Design", J.Cooper's "The Design Patterns Java Companion", "Design Patterns Explained", "UML distilled" and "Refactoring". "Java Virtual Machine" after all - OOP (at least in Java variant) doesn't make mush sense without knowing how method dispatch works. Hardly qualified as " hear a detail about OOP"...
Now I wonder if OOP makes so much sense to you only because you aren't familiar with the
relational model.
What parts did the most sense to you?
1. "The problem is that OO is permeating my niche where it probably does not belong. Its few, rare benefits there do not justify the added complexity."
2. "I see the OO side of the story all the time, but rarely are the down-sides mentioned."
3. "Claimed that OOP version was better without saying exactly why. You must be able to trace and articulate your mental steps, or provide clear metrics. "Emotional votes" don't count because nobody can externally verify them. Constructs and arrangements that make your own mind happy may not do the same for other brains, being that people are different from each other."
4. "I am the product of the same education process that most of the other programmers out there get. <...>If I am uninformed, then so are most OOP programmers. If you agree with this, then OOP is doomed because the industry is not presenting (training) OOP properly and most people will not spend 5 years on a mountain top with gurus to get there. My alleged ignorance may simply be a mirror to a much larger problem."
- to start with... :roll:

[Mapraputa Is]

I wrote to my former co-worker in Russia and asked what he thinks about OOP (and whether they use it already or not). He is not a programmer, he is a physicist by education, then he did a lot of statistical calculations, has some works in theory of classification and recently got his PhD in economics. So his views can be orthogonal to those of a programmer but I found them interesting nevertheless. (bad translation is mine)
"Well, now serious. When I for the first time read about OOP I got excited: "This is what I need". But having read about C++... I am not so determined to set up to investigate heaps of classes and constructors. My impression is that someone ingenious has thought up remarkable cubes, played a little, and then canonized not cubes, but consequences of his games.
Language developers play fool when they say their creations are a complete product, or they do not understand what they have done. All this is similar to debris of somebody's world view, not always interesting for other, unfinished ambitious projects etc. (I am a little angry because had been disappointed several times after having been alluded by slogans of the next computer masterpiece). I have my own hypothesis. OOP is a language for system analytics. If programmers start to use it, the result is nonsense".
I particularly liked the claim that OOP is not for programmers.
It is said that "Objects hide implementation complexity, yet they expose modeling complexity". Kyle Brown keeps on asking people to read at least one book before starting to model anything, but they prefer to ask "tell me which pattern I can use..." This is a cultural clash. Programmers need "complete practical code", they do not need patterns. To build models, they simply lack proper education. At least, I know I do.
[ September 01, 2002: Message edited by: Mapraputa Is ]

[Ilja Preuss]

Originally posted by Mapraputa Is:
What is probably hindering you is that you always try to compare what you learn about OOP to the relational way.
What's hindering me most is that I see the Solution, but I do not see the Problem this Solution is for.

The problem OOP tries to be a solution to is simply that of decoupling: how can I decouple things from one another which change for different reasons.

What I observe is that what was simple with my old set of tools, with OOP getting unnecessarily complicated.

What you see as complicated may possibly only be unfamiliar to you - and it probably motivates you to stop before you can start to observe the advantages. That is only my best guess - I might be terribly wrong, of course...

You are saying: OOP is good for quick prototyping. Isn't it what scripting languages are for? Jython, for that matter...

First, I didn't - and wouldn't - say that. I don't have any experience with prototyping, as when working XP-style, you very seldom have to do it.
Second, I am confused - isn't Jython an OO scripting language???

We worked with Clarion - template-based code generation engine. It was damn fast to develop a full-blown application, a lot of typical tasks were "encapsulated" in templates and if you need to adjust something - there are a lot of places you can plug in your code. It was easy to use, and what's better, templates were written for many languages, maybe even for Java (we didn't use it that time), so your application can be generated in any language you want. If there is no template - write your own. I guess, the same methoda wouldn't work if we were to computerize a giant enterprise, but we were not.

I don't get your point here - isn't code generation orthogonal to OOP?

Another thing, it's hard to make estimations, but roughly 30-50% of my time was devoted to "write once and throw away" code. Endless data format conversions, data mining, etc. I really do not need all complexity of OOP for that :roll: The code was written "from scratch", nothing to "inherit" from, and nothing to "demise".

If you don't need it, don't use it.
OTOH, I suspect that your code wasn't *totally* different every time - there certainly were recurring parts, at least in structure. Perhaps some apt OOP techniques (or others, for that matter) would have helped to not having to write anything from scratch, but to reuse parts of your code instead of throwing it away?

You are saying: "OOP abstractions are useful". No doubt they are useful. Look at this post in our XML forum. Who will say the first solution isn't useful? Of course, it is. It's just that the second is much simpler and more elegant.

That has nothing to do with OOP - the first solution is plainly procedural and simply using the wrong tool, as Dan suggested. Gerd even admitted that "It's just a quick and dirty hack."

You hear a detail about OOP, try to interpret it in the relational world and come to the conclusion that it doesn't make sense. You don't know that it does make sense in the OO world, because you are not familiar with it.
Let's see, I got "A" and "A+" in my college classes, I got my SCJP with 94% (it's not "developer" yet something), I read Grady Booch "Object-Oriented Analysis and Design", J.Cooper's "The Design Patterns Java Companion", "Design Patterns Explained", "UML distilled" and "Refactoring". "Java Virtual Machine" after all - OOP (at least in Java variant) doesn't make mush sense without knowing how method dispatch works. Hardly qualified as " hear a detail about OOP"...

Sorry, I meant "familiar" in the sense of "conversant". You don't get conversant with something by hearing about it, but by practicing it for a reasonable time.

Now I wonder if OOP makes so much sense to you only because you aren't familiar with the
relational model.

No, it makes so much sense to me because it works wonderfully for me. Perhaps the relational model would even work better - honestly, I don't know. For me, OOP certainly works much better than procedural programming, though.

1. "The problem is that OO is permeating my niche where it probably does not belong. Its few, rare benefits there do not justify the added complexity."

How does that connect to "3. ... Constructs and arrangements that make your own mind happy may not do the same for other brains, being that people are different from each other."?
Perhaps OO is introduced in that niche by people whos minds are made happy by it?
Additionally, why isn't he battling the introduction of OOP in that niche then, instead of battling OOP as a whole???

2. "I see the OO side of the story all the time, but rarely are the down-sides mentioned."

So he didn't read Bloch?
Seriously - should that be a reason to dismiss OOP, or should it simply be a reason to be very observant while learning it?

3. "Claimed that OOP version was better without saying exactly why. You must be able to trace and articulate your mental steps, or provide clear metrics. "Emotional votes" don't count because nobody can externally verify them.

When emotional votes don't motivate you to try something which might make your life easier, it's your problem, not mine.

Constructs and arrangements that make your own mind happy may not do the same for other brains, being that people are different from each other."

So he is accepting that OOP might be the perfect match for the majority of developers out there and just not appropriate for his brain? So, what is all the fuss about???

4. "I am the product of the same education process that most of the other programmers out there get. <...>If I am uninformed, then so are most OOP programmers. If you agree with this, then OOP is doomed because the industry is not presenting (training) OOP properly and most people will not spend 5 years on a mountain top with gurus to get there. My alleged ignorance may simply be a mirror to a much larger problem."

Well, as you already mentioned, most programmers are even less well informed about the relational model. What does that tell us?
BTW, it doesn't take "5 years on the mountain top with gurus" to get OOP. What it takes is working closely with an experienced OO-developer - which should be aboard any OO project anyway.
[ September 01, 2002: Message edited by: Ilja Preuss ]

[Mapraputa Is]

The problem OOP tries to be a solution to is simply that of decoupling: how can I decouple things from one another which change for different reasons.
This is what baffles me: why first to couple data and code, then to couple coupled data and code (objects) by arranging them in hierarchies, and then work hard on decoupling things from one another... Maybe in the final result this strategy does yield better decoupling than if we didn't perform any coupling in the first place, I do not know. Need to investigate more...
What you see as complicated may possibly only be unfamiliar to you - and it probably motivates you to stop before you can start to observe the advantages. That is only my best guess - I might be terribly wrong, of course.. .
"motivates you to stop" - no, I am not going to stop. My mistake was that I tried to understand a system (OOP in this particular case) from inside of system only (by reading OOP gurus). It never works. To fully understand something you need to see it in broader context, you need a theory in which OOP is only one particular case of some general rule. I am trying to find such a context. To start with, James Coplien's work can probably provide some insight...
Second, I am confused - isn't Jython an OO scripting language???
"OOP" and "scripting" are orthogonal concepts Means that there are scripting languages that aren't object-oriented, as well as those that are. I mentioned Jython because it's so well integrated with Java.
I don't get your point here - isn't code generation orthogonal to OOP?
It is. Means that there are code generators that do not employ OOP concepts, as well as those that do. I happened to use one that didn't have any notion of OOP. My point was that in some cases other techniques can do the job without overhead of OOP.
This is from Eric Evan's domain language book Kyle Brown suggested:
"If this pattern is applied consciously, a team can avoid taking on a great deal of overhead that is required to attempt other approaches. The common, costly mistake is to build an infrastructure and use tools much heavier weight than are needed, or to undertake a sophisticated design approach that you aren’t committed to carrying all the way.
Most flexible languages (such as Java) are overkill for these applications and will cost you dearly. A 4-GL style tool is the way to go."
Now I should probably say that the book explain all shortcomings and possible dangers of this approach as well, on page 39. Since the book is available for everybody to read, I think I can free myself from responsibility of providing a full quote. I hope I wont be accused in undermining high level of debates or something.
That has nothing to do with OOP - the first solution is plainly procedural and simply using the wrong tool, as Dan suggested. Gerd even admitted that "It's just a quick and dirty hack."
The first solution is not plainly procedural. All virtues of OOP -- interfaces, incapsulation, casts are here. Real opposition is not "OOP vs. procedural", but "imperative" vs. "declarative". OOP is certainly more "imperative" programming style than SQL or XPath. As to "wrong tool" - this is precisely my point. OOP is a wrong tool here. What Dan suggested, is to use OOP wrappers around an XPath expression. XPath does all the job, NodeIterator only presents results as objects. Now XPath itself can be implemented in OO language, and I suspect it is, but this has nothing to do with choosing a right tool for the job.
How does that connect to "3. ... Constructs and arrangements that make your own mind happy may not do the same for other brains, being that people are different from each other."?
Why should it connect?
Perhaps OO is introduced in that niche by people whos minds are made happy by it?
Perhaps. There is a powerful source of this happiness: educational system. You see, classes that I took in college were called "Computer Science-1" and "Computer Science-2". 98% of content was OOP (in Java variant), Java as such and Java's noble APIs. With some minor digressions into how computer represents integers and float-point numbers. Now *this* is Computer Science? I suppose that students' "minds were made happy by it", yes, because they didn't get a chance to learn anything else. They have to learn OOP before they acquire enough knowledge to make their own informed opinion. All this is not OOP's fault, of course, rather "how system works"...
Additionally, why isn't he battling the introduction of OOP in that niche then, instead of battling OOP as a whole???
I guess, mostly he reacts and sometimes overreacts at all the hype around OOP, but there is more to it, which deserves a separate post...
So he is accepting that OOP might be the perfect match for the majority of developers out there and just not appropriate for his brain? So, what is all the fuss about???
How did we move from "your own mind" to "majority of developers out there"?
Well, as you already mentioned, most programmers are even less well informed about the relational model. What does that tell us?
That OOP is oversold and overhyped and the relational model is not? And that all this is orthogonal to their real qualities, whatever they are?

[Ilja Preuss]

Damned! That is already the second time UBB quashed my response because there were more than 8 images (smileys?) in it. The work of 1,5 hours lost...
Perhaps sometimes I will learn to copy my response to the clipboard before submitting... :roll:
Now you will have to wait a day - I go to bed... <sigh>

[Mapraputa Is]

A-ha! This gives me a perfect opportunity to sneak some more posts before you got a chance to reply to previous ones...
Ilja wrote:
So he is accepting that OOP might be the perfect match for the majority of developers out there and just not appropriate for his brain? So, what is all the fuss about???
Quote from the abusive text :
--------------------------------------------------------------
"I often hear OO proponents say something along the lines of, "I always built my software in an OO-ish way, I just did not have a name for it. Then OOP formally came along and I was happy to see it built into the language."
I, on the other hand, think best in terms of tables and like to organize software projects using control tables. I have seen others do the same without ever knowing that they were using a "table paradigm."
--------------------------------------------------------------
I can say the same about myself. I always believed it's because of my relational past, but more interesting speculations can be made...
Robert Sternberg classifies thinking styles on various grounds, and one of divisions distinguish the following: "Monarchic", "Hierarchic", "Oligarchic", and "Anarchic" styles. This is from his tests:
The hierarchic style:

I like to set priorities for the things I need to do before I start doing them

Before starting a project, I like to know the things I have to do and in what order

When working on a task, I can see how the parts relate to the overall goal of the task

The oligarchic style:

When I undertake some task I am usually equally open to starting by working on any of several things

Usually when I have many things to do, I split my time and attention equally among them.

Usually when working on a project I tend to view almost all aspects of it as equally important.

...
I would say that whereas I can learn the need to set priorities, "oligarchic" style is more natural to me. I can be totally off here, but maybe this somehow contributes to "OOP vs. RM" preferences.

[Mapraputa Is]

Ilja wrote:
Additionally, why isn't he battling the introduction of OOP in that niche then, instead of battling OOP as a whole???
He believes that OOP was introduced in niches where it isn't a good fit because of hype, so he is trying to debunk hype. And by the way, he doesn’t concentrate on OOP only, I found anti-SQL and anti-XML rants on his site. You can call it "critical thinking" - and I would say it's a rare set of skills nowadays!
I got an impression he *is* intellectually honest, which doesn't mean he is always right. Partcularly, this passage bothers me:
"Many OOP proponents brag about OOP's alleged elimination of "case" or "switch" constructs. Case statements are a favorite (straw-man) whipping boy for OO textbooks and fans. In reality what is being done is that the case statements are being broken up and spread around the program so that they are not immediately visible. Their equivalent is still there, but simply morphed and divided."
"spread around the program" - perhaps, but I think one potentially important thing is missing: with "switch" (of if-else for that matter) construct you can only have limited number of alternatives, whereas when you replace it with polymorphic method calls, you can add infinite number of alternatives - this jump to infinity shouldn't be ignored.

[Ilja Preuss]

Originally posted by Mapraputa Is:
I would say that whereas I can learn the need to set priorities, "oligarchic" style is more natural to me. I can be totally off here, but maybe this somehow contributes to "OOP vs. RM" preferences.

I see how you would come to that conclusion by studying "traditional" OO textbooks. But in my experience, OOP is also perfectly suited for more ad hoc, even evolutional development. After all, XP evolved in an OOP environment.

[Ilja Preuss]

Originally posted by Mapraputa Is:
The problem OOP tries to be a solution to is simply that of decoupling: how can I decouple things from one another which change for different reasons.
This is what baffles me: why first to couple data and code,

Code is coupled to the structure of data by accessing that data, not by putting it in the same class. The only way I know to decouple code from data is to abstract away from the data.
That is excatly what information hiding is about: All code outside of a class doesn't access its data directly, but through the interface of that class.
Of course we have still code left that is coupled to the data - but by encapsulating it in the same class, we made that coupling explicit. In a well designed OO system, changes to data structure should only affect the code of the class the data resides in.

then to couple coupled data and code (objects) by arranging them in hierarchies, and then work hard on decoupling things from one another...

The point is not to decouple everything from everything else - that would be a waste of effort and probably even impossible.
The point is to decouple things that will change for different reasons and put things together that will change for the same reasons. Subclassing is a compromise between those two forces, and for some cases the most appropriate solution.
As Larman puts it in Protected Variation: The Importance of Being Closed:
"Low coupling and protection against variations is not motivated in all areas. You must pick your battles in design, be they at the macro-architectural level or the humble instance field. A good designer can identify the likely points of instability or variation and apply PV to those points but not others. Otherwise, effort is wasted
and complexity may arise (and with it, the chance for defects)."

"motivates you to stop" - no, I am not going to stop.

OK.

My mistake was that I tried to understand a system (OOP in this particular case) from inside of system only (by reading OOP gurus). It never works. To fully understand something you need to see it in broader context, you need a theory in which OOP is only one particular case of some general rule. I am trying to find such a context.

Mhh, I am not sure that that is what *I* would need, but if it will help you, fine!

To start with, James Coplien's work can probably provide some insight...

I will take a look at it.

"OOP" and "scripting" are orthogonal concepts Means that there are scripting languages that aren't object-oriented, as well as those that are. I mentioned Jython because it's so well integrated with Java.

So, if scripting is for prototyping and OOP is orthogonal to scripting, does it follow that OOP necessarily is orthogonal to prototyping? I don't think so...

I happened to use one that didn't have any notion of OOP. My point was that in some cases other techniques can do the job without overhead of OOP.

OOP is not an "all or nothing" thing. You can write perfectly procedural code in Java. Hell, most Java code I see *is* way too procedural for my taste... :roll:
So, certainly you only should apply OOP where it helps you doing your job, yes.

This is from Eric Evan's domain language book Kyle Brown suggested:

Another thing to read - whew...

The first solution is not plainly procedural. All virtues of OOP -- interfaces, incapsulation, casts are here.

Casts are totally orthogonal to OOP - there are casts in C, whereas in Smalltalk you don't need such a concept.
Regarding interfaces and encapsulation: Just using an OO API doesn't make the solution itself OO.
An OO solution would have more likely looked something like

students.getByMnr(12345).getGrade(Course.SEM)

What we have done here is decoupling the code representing a specific query from the code that knows how to perform a query. We can write more queries without having to know about how the data is stored. And we can change the storage and query system to RDBMS/SQL, OODBMS, LDAP, property files or the "yet to be invented new hype of the future" without having to touch the code of the actual queries itself - we can even switch between them at runtime.
Of course, for a simple throw-away solution that would be total overkill - if you know for sure that it always only has to work for XML files and/or that it will always only contain that one query, by god, go with directly using XPath!

What Dan suggested, is to use OOP wrappers around an XPath expression. XPath does all the job, NodeIterator only presents results as objects. Now XPath itself can be implemented in OO language, and I suspect it is, but this has nothing to do with choosing a right tool for the job.

Yes, correct.
[ September 03, 2002: Message edited by: Ilja Preuss ]

[Ilja Preuss]

Originally posted by Mapraputa Is:
How does that connect to "3. ... Constructs and arrangements that make your own mind happy may not do the same for other brains, being that people are different from each other."?
Why should it connect?

Well, for me "Constructs and arrangements that make your own mind happy may not do the same for other brains" implies "those that do not make your own mind happy may do so for others". And that doesn't seem to connect to "Its few, rare benefits there do not justify the added complexity" until you add an " - for me, at least".

Perhaps OO is introduced in that niche by people whos minds are made happy by it?
Perhaps. There is a powerful source of this happiness: educational system. You see, classes that I took in college were called "Computer Science-1" and "Computer Science-2". 98% of content was OOP (in Java variant), Java as such and Java's noble APIs. With some minor digressions into how computer represents integers and float-point numbers. Now *this* is Computer Science? I suppose that students' "minds were made happy by it", yes, because they didn't get a chance to learn anything else. They have to learn OOP before they acquire enough knowledge to make their own informed opinion. All this is not OOP's fault, of course, rather "how system works"...

Well, my experience seems to be radically different from yours: our first semester was about functional programming, the following three about imperative/OO, declarative and machine-oriented (assembler). But it seemed to me as if every paradigm only was scratched on the surface - if you really wanted to know what it was about, you had to dig deeper for yourself...
BTW, I doubt that many of the current experienced OO advocates are influenced by the educational system in the way you describe - many of them are in software development for decades and I would be surprised if OOP was a main focus of their early education...

So he is accepting that OOP might be the perfect match for the majority of developers out there and just not appropriate for his brain? So, what is all the fuss about???
How did we move from "your own mind" to "majority of developers out there"?

By the small word "might". It is a possibility, isn't it?

Well, as you already mentioned, most programmers are even less well informed about the relational model. What does that tell us?
That OOP is oversold and overhyped and the relational model is not?

Possibly.
What should we do about it?

And that all this is orthogonal to their real qualities, whatever they are?[/QB]

Certainly - if distribution were connected to quality at all, Smalltalk would already have taken over the world...

[Ilja Preuss]

Originally posted by Mapraputa Is:
I got an impression he *is* intellectually honest, which doesn't mean he is always right.

Yes, I think he is honest. From discussions at the usenet I think he isn't a good listener, though...

Partcularly, this passage bothers me:
"Many OOP proponents brag about OOP's alleged elimination of "case" or "switch" constructs. Case statements are a favorite (straw-man) whipping boy for OO textbooks and fans. In reality what is being done is that the case statements are being broken up and spread around the program so that they are not immediately visible. Their equivalent is still there, but simply morphed and divided."
"spread around the program" - perhaps, but I think one potentially important thing is missing: with "switch" (of if-else for that matter) construct you can only have limited number of alternatives, whereas when you replace it with polymorphic method calls, you can add infinite number of alternatives - this jump to infinity shouldn't be ignored.

Well, at least an *undefined* number of alternatives - it's the OO-typical decoupling again: the code using the alternatives doesn't depend on the actual alternatives, but only on an generalized abstraction.

[Ilja Preuss]

Originally posted by Mapraputa Is:
But having read about C++...

Ouch...

I am not so determined to set up to investigate heaps of classes and constructors.

So, does that mean that OO APIs are more complex than non-OO APIs providing the same functionality???

My impression is that someone ingenious has thought up remarkable cubes, played a little, and then canonized not cubes, but consequences of his games.

Sorry, I don't get the meaning of this sentence...

I have my own hypothesis. OOP is a language for system analytics. If programmers start to use it, the result is nonsense".

Well, my hypothesis is that when programmers have to implement a design resulting from OOA/D without consideration of the implementation, the result will most probably be nonsense.
OTOH, when insights from implementation are used as feedback for analysis and design, applying OO principles can be remarkably rewarding, IME.

I particularly liked the claim that OOP is not for programmers.

I thought that P stands for programming. If it isn't used to make the life of the programmers more easy, it is misused, in my not so humble opinion.

It is said that "Objects hide implementation complexity, yet they expose modeling complexity".

Who is saying that?

Kyle Brown keeps on asking people to read at least one book before starting to model anything, but they prefer to ask "tell me which pattern I can use..." This is a cultural clash. Programmers need "complete practical code", they do not need patterns. To build models, they simply lack proper education. At least, I know I do.

You seem to think that patterns are more about models than about practical code???

[Ilja Preuss]

Originally posted by Ilja Preuss:
Well, at least an *undefined* number of alternatives - it's the OO-typical decoupling again: the code using the alternatives doesn't depend on the actual alternatives, but only on an generalized abstraction.

BTW, this is called the Dependency Inversion Principle.