please comment-OOP BAD

[Beny Na]

hi all,
i have read the following articel on a web site:

http://www.geocities.com/tablizer/oopbad.htm

i don;t really have much experience involving in such a big project using OO..

anyone who has an experieces using OO for large project and advantages using OO methodologies over others, please give a comment..

thanks

[Scott Ambler]

Looks to me like yet another data dinosaur who just doesn't get it. Like it or not, we use OO technology on the front end and RDB on the back end. This person needs to accept this and find ways to make the technology work. Rants which basically boil down to "let's go back to the old days" really don't make much sense. These writings are probably a reflection of the cultural impedance mismatch.

Some of his issues are valid, but for the most part it shows a lack of understanding of OO. Read about OO, read about non-OO, then figure out how to meld the two for yourself. You might find that theAgile Data Site presents a more balanced view, but that's something that you need to decide.

- Scott

[Thomas Paul]

I don't think that is a particularly useful comment. Calling people "dinosaurs" because they don't agree with you is probably not what the person who started this thread was looking for. Your comment can basically be summarized as "that guy needs to shut up and drink the kool-aid." In fact, it reminds me of what the Agile followers say about the RUP guys.

[Ernest Friedman-Hill]

On the first page of the site, he talks about how pro-OO arguments are often just again "straw men" -- i.e., OOP is argued to be superior to characteristics that procedural programs don't really have. Then, in the long page on "Table Oriented Programming", he's guilty of exactly the same thing -- for example, decrying OOP for giving rise to programs with hundreds of lines of

foo1.bar = 1;
foo2.baz = 2;
foo3.bam = 3;
foo1.foo = 4;

But of course, if you're doing that, you're sure as hell not doing OOP. He also calls VB an OOP language, which is pretty funny.

There's room for everybody at the table. A single system will often have OOP parts, and procedural parts, and relational parts, etc. Use the best tool for the job. If something is ugly and complex, you're probably using the wrong tool.

[Ilja Preuss]

There have been some rather long discussions on the topic in the past:

https://coderanch.com/t/99442/patterns/OOP-Much-Better-Theory-Than

https://coderanch.com/t/99248/patterns/Table-Oriented-Programming

https://coderanch.com/t/99377/patterns/Chained-if-else-statements-avoid

[Ilja Preuss]

Originally posted by Scott Ambler:
Rants which basically boil down to "let's go back to the old days" really don't make much sense.

As far as I know, that's actually not his position. Instead, he says that what he calls "Table Oriented Programming" doesn't get enough attention because of all the OO hype.

Ironically, he totally misses that the jump tables that are typically used to implement polymorphism in OO languages look very much like the TOP paradigm he proposes. I've tried to discuss this with him, but he insisted that OOP is mainly about building huge class hierarchies build around nouns.... :roll:

[Ilja Preuss]

Originally posted by Thomas Paul:
Calling people "dinosaurs" because they don't agree with you is probably not what the person who started this thread was looking for.

I agree. Fortunately, Scott did a little bit more than that, didn't he?

Your comment can basically be summarized as "that guy needs to shut up and drink the kool-aid."

Did you read the website? What's *your* opinion on it?

To me it seems to be quite obvious that the author doesn't understand what OOP really is about. And until he does, his writings will continue to be misleading, if not plain wrong.

In fact, it reminds me of what the Agile followers say about the RUP guys.

So how is this a more helpfull comment than calling someone a dinosaur?

No hard feelings...

[Ilja Preuss]

Originally posted by Ernest Friedman-Hill:
On the first page of the site, he talks about how pro-OO arguments are often just again "straw men"

Well, of course in many cases he is actually right. But from that it simply doesn't follow that OO is useless, as basic logic should tell.

[Thomas Paul]

I agree. Fortunately, Scott did a little bit more than that, didn't he?

Actually, no, he didn't. He gave a link to an article. I'm sure the person who wrote the original question knows what google is.

Did you read the website? What's *your* opinion on it?

I think the autor of the website is wrong. He fails to address questions of reusability and maintainability. But I think to properly address his comments requires a lot more effort than I am willing to give.

So how is this a more helpfull comment than calling someone a dinosaur?

Didn't you see the smiley? It was meant to be a joke. I did not get the sense that Scott was making a joke about the author of the web site being a dinosaur, did you?

[Ilja Preuss]

Originally posted by Thomas Paul:
I agree. Fortunately, Scott did a little bit more than that, didn't he?

Actually, no, he didn't. He gave a link to an article. I'm sure the person who wrote the original question knows what google is.

Then it's probably best to agree to disagree here. I didn't find his post to be overly helpfull, but think it had *some* content. I'm not even sure I could easily get google to connect the two links to the original question of this thread. Perhaps that's just me...

Did you read the website? What's *your* opinion on it?

I think the autor of the website is wrong. He fails to address questions of reusability and maintainability. But I think to properly address his comments requires a lot more effort than I am willing to give.

I can empathize with that sentiment. Thanks for explaining it!

So how is this a more helpfull comment than calling someone a dinosaur?

Didn't you see the smiley?

Did you see mine? I really just found it funny, in an ironic way. If you intended it to be, consider it being a success!

[Gerald Davis]

We often don�t talk about Functional programming methodology that is much different from Procedural. What is your understanding of Declarative Vs Imperative?
Procedural programming suffers from the weakness of Global Variable; Object Oriented Programming suffers from loads of mini global variables called class and instance variables. Function programming to overcome this problem by using nested function.
http://en.wikipedia.org/wiki/Declarative_programming This should fill you in more about what it is all about.

[Scott Ambler]

Calling people "dinosaurs" because they don't agree with you is probably not what the person who started this thread was looking for.

Actually, I called him a data dinosaur because it reflects my frustration with this community. I've been down this path numerous times with people like this, and it always ends up the same -- they don't understand what they're talking about, they don't have any experience with it, and they're trying to protect their own little empire within their organization.

Your comment can basically be summarized as "that guy needs to shut up and drink the kool-aid."

Actually, it boils down to "this person should wake up and smell the coffee." For all the ranting he does, he fails to mention the glaringly obvious fact that all the major DB vendors have OO offerings as well as their db offerings. Apparently there is a market for OO. He fails to mention that there are millions of OO programmers out there, or near-OO programmers out there if you include VB, and they've been successfully using the technology for years.

I'm sorry, but having dealt with people like this for years I've lost simply lost patience with them. Spend a few weeks on a data management list and you'll see what I mean.

There's room for everybody at the table. A single system will often have OOP parts, and procedural parts, and relational parts, etc. Use the best tool for the job. If something is ugly and complex, you're probably using the wrong tool.

Yes, which I have been saying, and writing about, for years.

As far as I know, that's actually not his position. Instead, he says that what he calls "Table Oriented Programming" doesn't get enough attention because of all the OO hype.

Actually, table-oriented programming is a pretty old idea which people still use in appropriate cases. It has gotten all of the attention that it warrants.

I think the autor of the website is wrong. He fails to address questions of reusability and maintainability. But I think to properly address his comments requires a lot more effort than I am willing to give.

I completely agree. I've spent time trying to help people like this, and it's not worth the effort.

I did not get the sense that Scott was making a joke about the author of the web site being a dinosaur, did you?

No, I wasn't making a joke. I called him a dinosaur to let the original poster know that this guy's writings reflected old thinking. It's the sort of stuff the data folks wrote in the early 90s. It was wrong then, and it's clearly wrong now.

I agree. Fortunately, Scott did a little bit more than that, didn't he?

Actually, no, he didn't. He gave a link to an article. I'm sure the person who wrote the original question knows what google is.

Actually, I did. At my sites I describe numerous techniques which people can apply to improve the way that they work with OO and relational technology. I also provide what I believe to be a fair comparison of various techniques when the situation warrants it.

How would you compare what I've written with what the other person has written?

Even if he knows what google is, do you think he'd actually read and understand anything that he would find? Clearly he hasn't been doing too good so far.

- Scott

[Stan James]

I spent an evening trying to write a response to OOP-BAD point by point, but many of the arguments there were too bizzarre to even parse. My effort didn't have a good flow and it was very repetitive and I got bored. Anyway, TopMind has been beaten up enough my many better than I on Ward's Wiki and other forums.

To say there are other valid coding paradigms is fine. To say some other is better for some particular job is fine. To say "OO is bad" is silly. Enough organizations and individuals have demonstrated some value or another of OO to themselves that it's clear "OO is good" for some jobs.

Personally, I enjoy practicing the best OO I can at all times on large and small and throwaway code just to stay in shape. Test first, refactor, watch dependencies carefully. I also use scripting tools like REXX when they are better for the job. Then I practice the best functional decomposition I can.

[Ilja Preuss]

Originally posted by Scott Ambler:

Even if he knows what google is, do you think he'd actually read and understand anything that he would find? Clearly he hasn't been doing too good so far.

I think Thomas referred to Beny here, not to "TopMind".

[Stan James]

We didn't do too well with the original question:

anyone who has an experieces using OO for large project and advantages using OO methodologies over others, please give a comment.

Ilja gave a really nice answer the other day to "what is OO", something about an effective set of tools for managing dependencies. One of the things that distinguishes OO from other paradigms is how we decide what kinds of dependencies between units of code are good and bad. The features of OO that you usually see - inheritance, encapsulation, etc - are among the tools, along with some formalized patterns and principles of design.

We OO fans believe our choices around dependencies will yield more cost effective change and reuse over a long period of time. (Maybe not the easiest possible code to read or the fewest possible lines of code or the earliest delivery.) We strive to reduce dependencies on the things we predict will change so the overall design can survive significant change in well-isolated places.

The OO-Bad page (and one or two folks around here) will tell you they prefer discrete bits of code that can accept all the data they need as parameters over an object that provides certain behavior around private data. They have thought through their own values for good and bad dependencies and many other aspects of quality. More power to them, I guess, as we compete in the market place. I'm not going to say I do better work than Steve Gibson (grc.com) who works exclusively in assembler, but I do better work in OO than I would otherwise.

[Stan James]

We didn't do too well with the original question:

anyone who has an experieces using OO for large project and advantages using OO methodologies over others, please give a comment.

Ilja gave a really nice answer the other day to "what is OO", something about an effective set of tools for managing dependencies. One of the things that distinguishes OO from other paradigms is how we decide what kinds of dependencies between units of code are good and bad. The features of OO that you usually see - inheritance, encapsulation, etc - are among the tools, along with some formalized patterns and principles of design.

We OO fans believe our choices around dependencies will yield more cost effective change and reuse over a long period of time. (Maybe not the easiest possible code to read or the fewest possible lines of code or the earliest delivery.) We strive to reduce dependencies on the things we predict will change so the overall design can survive significant change in well-isolated places.

The OO-Bad page (and one or two folks around here) will tell you they prefer discrete bits of code that can accept all the data they need as parameters over an object that provides certain behavior around private data. They have thought through their own values for good and bad dependencies and many other aspects of quality. More power to them, I guess, as we compete in the market place. I'm not going to say I do better work than Steve Gibson (grc.com) who works exclusively in assembler, but I do better work in OO than I would otherwise.

PS: I introduced "TopMind" to the discussion (or I think I did) as someone who has written extensively on table-oriented stuff and object-bad stuff. I think the OO-bad page linked originally quotes him but is not necessarily his. Anyone know fer sure?

[Scott Ambler]

quote:
--------------------------------------------------------------------------------
Originally posted by Scott Ambler:

Even if he knows what google is, do you think he'd actually read and understand anything that he would find? Clearly he hasn't been doing too good so far.

--------------------------------------------------------------------------------



I think Thomas referred to Beny here, not to "TopMind".

Oops, I sincerely apologize then. I was referring to "TopMind", not Beny.

- Scott

[Ilja Preuss]

Originally posted by Stan James:
PS: I introduced "TopMind" to the discussion (or I think I did) as someone who has written extensively on table-oriented stuff and object-bad stuff. I think the OO-bad page linked originally quotes him but is not necessarily his. Anyone know fer sure?

I'm quite sure that it's *his* site.

[Beny Na]

attn : scott
----------
I agree. Fortunately, Scott did a little bit more than that, didn't he?

Actually, no, he didn't. He gave a link to an article. I'm sure the person who wrote the original question knows what google is.
------------

Actually, I did. At my sites I describe numerous techniques which people can apply to improve the way that they work with OO and relational technology. I also provide what I believe to be a fair comparison of various techniques when the situation warrants it.

How would you compare what I've written with what the other person has written?



Even if he knows what google is, do you think he'd actually read and understand anything that he would find? Clearly he hasn't been doing too good so far.
b: Scott, i just want emphasize my posting purpose : to share experiences when using OO for large projects.
i have been programmin using C++ over 5 years and java over 3 years, i understand how OO work and procedural. But i never get involved in large projects, and i do understand what the website(google) said.
THe main point is, i want to share your knowledge about the author website, nothing more, thats all.


what do you mean by saying : "Clearly he hasn't been doing too good so far."?



th

[Ilja Preuss]

Originally posted by Beny Na:

what do you mean by saying : "Clearly he hasn't been doing too good so far."?

As Scott wrote above, he referred to the author of the website, not to you. It was just a misunderstanding.

[Ilja Preuss]

I'm working on a system consisting of approximately half a million lines of code, distributed over 80+ CVS modules. To me that kind of qualifies as "not small".

It is now used in production for over seven years, and continuously extended in significant ways, including the integration of a diverse set of other systems.

Using OO techniques to manage the source code dependencies helps us a great deal in keeping the system extendable and maintainable. In fact, since some good OO developers joined the team, the system has become significantly *more* flexible while growing.

So, from my experience, applying OO techniques to large systems makes a lot of sense. After all, the bigger the project, the more important managing dependencies becomes.

[Sol Mayer-Orn]

I agree with the great reply supplied by Stan James.

My 2 cents:

1. Depends what you're writing.
An experienced OO programmer should have the confident to tell when it's not worth it to get into "over design", and when simple data-orienced approach should be enough.

If you're writing a framework or a set of general-purpose, re-usable components, you'll probably have to go with OOP, and furthermore, use some fancy design patterns - probably starting with the "Stragety" (or "Policy") pattern, which lets the user "plug" new customized behaviors into the existing system.

On the other end of the scale, there are some small IT projects (not all of them!) where components are simple, and code duplication is not the end of the world. If you have 2 screens with *some* points of similarity, and you don't expect to have much more - is it really worth the trouble to find the common parts and move them into, say, a base class ? Will the sky fall if you don't ? Maybe you can wait and do it only if there's demand for more screens (that's part of the Xtreme programming approach).

2. Still, it's important to have the knowledge. There's a world of difference between a beginner saying "I'm not going to invest in OO design because I've *heard* it's just a hype", and an experienced, "battle-scared" guy stating "this situation classically calls for the Decorator approach, but from my experience, after having written 10 projects with a Decorator and 12 projects without it, I can tell that in our case it would be over-desing and not worth the tradeoffs".

3. OOP is great, but far from perfect.
It has saved me lots of work, but on some occasions I've found myself forced to produce code that's duplicated or hard to maintain, and the problem was traced to limitations of OOP or java. Some obvious examples: lack of "multi polymorphism" (usually solved by "double dispatch", but that's actually compensating for limitations of the compiler); issues raised by supporters of "aspect oriented programming"; or the lack of generic types ("templates") before the advent of java 5.

Personally, I still find OOP incredibly useful & time saving. It's great, it's just not an omnipotent idol or a magic cure (which is how it's sold on some books / academic courses).
Kind of like my old car - does a great job taking me to work, I'd never give it up, but I don't live under the illusion it could take me to the moon, or bring about world peace...

[Ilja Preuss]

Originally posted by Sol Mam-Orn:
If you have 2 screens with *some* points of similarity, and you don't expect to have much more - is it really worth the trouble to find the common parts and move them into, say, a base class ? Will the sky fall if you don't ? Maybe you can wait and do it only if there's demand for more screens (that's part of the Xtreme programming approach).

No, that's not part of XP. XP is *very* fussy about removing duplication, every time. And for a good reason.

In my experience, when you don't do it, the following happens: your small application (probably even meant as a prototype) goes into production. The users have this idea for a third screen. You implement it, and because it's just a small change, you again don't take the time to remove the duplication (which now actually becomes triplication). And so it continues for some weeks. No, the sky won't fall on you. It will just get harder and harder to change or extend the system, until you finally discover that you have build your next "small" legacy system, finding yourself in maintenance hell.

It's much better to remove any duplication as soon as you notice it. If you think about it, it will typically be the point in time when it will take the least effort to do so, anyway.

What you've probably confused this with is XP's mantra of "You Ain't Gonna Need It". This, though, refers *exclusively* to features, not to code structure! One of XP's basic assumptions is that you *will* need the best code structure you can get, always.

[Sol Mayer-Orn]

It's much better to remove any duplication as soon as you notice it. If you think about it, it will typically be the point in time when it will take the least effort to do so, anyway.

Of course everyone's entitled to their own opinion...
Personally, I agree that most "duplication removal" is indeed highly recommended. If both your screens have a the same header panel, differing only in (say) backgroud color - then by all means, move it into a single common component, ASAP.

However, experience shows it's not always that simple...
Some very simple examples:

1. If one screen handles "int" values, and the other screen handles "Strings", then any attempt to unify them would probably mean working with "Objects" (assuming you work in java 1.4, not 5). Which means you loose readability, compile-time type check, and sometime performance.

2. We once had a system doing mediacal/phisical calculations, and we made a substantial effort to unify similar calculations - only to find out that some similarities were coincidental, and evolved in different directions as the spec matured.

3. Some duplications may only be solved using Aspect Oriented concepts, or related solutions (meaning you resort to AOP tools, or proxies, or automatic code generators).

Bottom line, I agree that duplication should be avoided, but with propertion. I'd consider letting it go if (and only if) there's *little* common functionality *and* refactoring causes big trouble (loss of type-safeness, becoming a guinee pig for buggy AOP tools, etc).

Then again, it's a personal choice, as I mentioned everyone's entitled to their own opinion