OOP is it impraticle?
I was perusing the Wikipedia entry for OOP and looking at a few of the criticism links. To me the arguments aer based on things that OOP supposedly says but that I don't really consider OOP.
http://en.wikipedia.org/wiki/Object_oriented_programming#Criticism
Perhaps they misunderstand OOP. Perhaps I'm not using OOP but rather some sort of bastardized hybrid. I do think that what I consider OO is not what I've read about or seen described in a lot of places. I've been influenced by the Interface concept such that I only consider OO concepts important at key 'gateways' or communication points in the program. Behind the scenes, (e.g. implementation classes) I have no problem violating OO principles because it's not part of the public API.
Those of you who feel you have used OO to it's fullest potential: do you think OO is an effective way to program? Do you think pure OO (as an academic might describe it) is realistic?
[961 byte] By [
dubwaia] at [2007-10-2 9:37:56]
Way to mispell impractical, genius.
> Those of you who feel you have used OO to it's
> fullest potential: do you think OO is an effective
> way to program? Do you think pure OO (as an academic
> might describe it) is realistic?
No, I think OOP has been a failure all these years, and every system based on it should be scrapped. Let's go back to COBOL.
%
> > Those of you who feel you have used OO to it's
> > fullest potential: do you think OO is an effective
> > way to program? Do you think pure OO (as an
> academic
> > might describe it) is realistic?
>
> No, I think OOP has been a failure all these years,
> and every system based on it should be scrapped.
> Let's go back to COBOL.
So do you think that a lot of these arguments come from a misunderstanding of OO? It seems to me that OO is one of the most misunderstood concepts in programming in that a lot of people who think they understand it don't.
Ironically, that's one of the complaints about OO: that when people make arguments against it, they are always told they don't understand it. I guess if you are cynical, you might think that this is just a convienient way to defeat criticism of OO. However, I kind of think that it's kind of convienient to assume that this is just a convienient argument and that you do indeed understand when being told you do not. If you get my meaning.
Nobody understands OO.
Relational databases had E. F. Codd, who defined the field with his articles back in the 1970's. So now there isn't any argument about whether a database system is relational or not.
Whereas OO didn't have that foundation. So dozens of people have thrown out principles that they say are part of OO. That makes it easy for people to argue about whether something is or isn't OO. As the first link in that Criticisms section says, "The lack of consistency in OO methodologies and definitions makes it nearly impossible to make any statement about OO that all OO practitioners will agree with." Of course not all OO practitioners would agree with that.
So instead of Codd, you have codswallop.
I've been writing business programs for 30 years now. And looking back on the 25 years where I knew nothing about OO, I see hardly anything where OO would have made any difference. When you're dealing with customers and inventory and taxes where all the data is in SQL databases, OO isn't particularly helpful and when you try to use it, it just gets in the way. (Our systems aren't written in COBOL but I'm indirectly supporting Duffy's sarcastic comment here.)
That's not to say OO has no place in our business. We do have places where heterogeneous things are happening and we don't need to put them in rectangular boxes, and for those things OO is extremely useful. We have business partners sending us data in various forms through various channels and various things have to be done to that data before it's put into the rectangular boxes. That's where you can make use of the levels of abstraction that OO provides, and we've had a lot of success using it there.
But pure OO? Not in our business.
> But pure OO? Not in our business.
The way I see it, there are two flavors of OO, dogmatic OO and pragmatic OO. Dogmatic OO says that no matter how insignificant the code is and no matter whether the code is meant to be reusable, you need to follow strict inheritace and encapsulation.
In my mind, pragmatic OO finds common interface (normally a Java interface type but not always) points and abstracts them into a agnostic set of operations.Then implementors do what they need to do to implement this spec but it really doesn't matter if the underlying implementation is OO. Why should anyone on the other side of that facade care?
The point is that when I read the critiques, they don't seem to be describing what I do when I think I'm using OO.
> So do you think that a lot of these arguments come
> from a misunderstanding of OO? It seems to me that
> OO is one of the most misunderstood concepts in
> programming in that a lot of people who think they
> understand it don't.
If Paul Graham and Richard Gabriel don't understand OO, then what chance do I have?
And what's with that awful c2.com wiki? I can never make heads or tails of anything written on that stupid site. Which is strange, because I find wikipedia very readable. Maybe stronger editors on wikipedia...
>
> Those of you who feel you have used OO to it's
> fullest potential: do you think OO is an effective
> way to program? Do you think pure OO (as an academic
> might describe it) is realistic?
I know there have been successful non-trivial smalltalk applications.
And to my way of thinking smalltalk is as OO as you can get.
I also know that there have been many things introduced over the years for which, at least per the media (where developers most of the time provide the direct input) were certain to revolutionize the way programming occurred.
Most didn't.
If it was just hype that made something successful then there should be more successes.
So I suspect that there is something real in OO that makes it better than procedural programming. MIght not be substantially better but still better.
The problem with all these arguments is it's so hard to define what OO is, as has already been mentioned. I personally agree with your line of thinking with "dogmatic" and "pragmatic" OO beliefs. I couldn't say whether or not pure OO, meaning the dogmatic OO, is realistic because I honestly don't have the education or experience to make such a judgement. What I will say is that in Java I believe in the more pragmatic approach. There are a lot of "bad" practices out there that I believe may still be part of what I call an optimal solution. It may violate a general rule or principle, but if it's simpler and takes half the time in a situation where the disadvantages and problems have a tiny chance of ever being encountered why waste the time and money for the academic satisfaction of something being "pure"?
In fact, I think such an obsession over pure OO is akin to obsessing over performance. We all accept that premature optimization is "bad", yet creating an overly complex and convoluted API that takes twice the time just to avoid disadvantages we never would have encountered in the first place doesn't seem to register as an issue with people.
> No, I think OOP has been a failure all these years,
> and every system based on it should be scrapped.
> Let's go back to COBOL.
>
> %
To DrClap's point, I left a company that ran on 100% COBOL. I was a Java singleton in a sea of COBOL programmers.
Another interesting point from DrClap's note is that relational databases are still king for most persistence. A lot of the credit goes to the fact that Ed Codd laid down such a strong mathematical foundation. Object-oriented databases might be great data with long relational chains to follow (e.g., CAD data in complex models), but banks still keep their data in RDBs.
Languages aren't the solution. O-O might be hard, but breaking programming fundamentals like "don't repeat yourself" causes problems in every language. Tight coupling can be done in COBOL, too. I saw lots of cut & paste and tightly coupled code in those old COBOL systems, and often for the same reason: people who didn't know better did what they had to do to get their job done under tight deadlines.
You can't practice engineering without a degree, but you can become a "programmer" without any formal training beyond knowing language syntax. That's a problem, whether you practice O-O or not.
There are successful O-O applications. eBay is deployed on JEE. Isn't that a success?
I'd take articles like that with a grain of salt.
%
> breaking programming fundamentals like "don't repeat yourself" causes
> problems in every language
Truer words have seldom been spoken. This is the essence. Programming languages aren't (or shouldn't be) about following some strict doctrine out of principle. They should be about offering developers powerful features to enable re-use. And all the "holy principles" follow from this essence.
That, and the aspect of improving readability (allowing one to express the solution in terms similar to that of the problem domain), are essential in a professional environment.
If a paradigm or a specific language enables sufficient forms of re-use, and it can attract enough industry users to form a solid community, it's a success in my book. So I dare say OO and several languages supporting it are not a failure at all, from a profesional point of view. Academic views may disagree with this assesment of success or failure, of course :)
My 2c :)
Lokoa at 2007-7-16 23:44:04 >
> Those of you who feel you have used OO to it's
> fullest potential: do you think OO is an effective
> way to program? Do you think pure OO (as an academic
> might describe it) is realistic?
Well, I磀 say that if OOP is really used following its concepts and principles, and without bad practices, then we will have an almost effective way to program. That is almost because I agree with some points from the article you provided:
[url http://en.wikipedia.org/wiki/Object_oriented_programming#OOP_as_a_new_paradigm.2C_point_of_view_or_marketing_term]OOP as a new paradigm, point of view or marketing term★[/url]
Reusability is the benefit most often claimed for OOP. However, that is sometimes disputed as being a large or primary benefit. The ability to maintain a program once written, the ability to do localized debugging, and the ability to do much larger parallel development efforts are all cited as more significant reasons to use an OOP language.
In my particular case, this statement above is very true. I mean, at the company I work, we have reusability, but the main benefits that coming from OOP are the others: easier maintenance, fixing bugs without significant impact in the system, and parallel development.
> Why should anyone on the other side of that facade care?
Maybe nobody on the sunny side of the facade cares, but you should
care (the same counts for me too). I always design my classes on the
shadow side of the facade having basically one thing in mind. For
every single class I wonder: "can something/someone else do this?".
If so, I delegate the stuff, if not, it seems to be the responsibility of the
class I'm designing at the very moment. If I can delegate the stuff, I
ask myself the question "do I want to know the class that does the
stuff for me?". If so, I'm stuck to tight coupling, if not I feel relieved.
Another question I keep on asking myself is: "can others use my class
and can I (my class under construction) fulfill that demand?". If so, my
class is reusable and quite a general class. If not, my class is some
isolated thing, i.e. just good for one thing.
These few questions are paramount in every design I make and I don't
pay much attention to those patterns. The funny thing is that those patterns
sort of "see the light" automatically.
I go quite far, almost in a "fractal" type of way. It always pays back, i.e.
I can change about everything on the shadow side of the facade without
the sunny side knowing anything about it.
IMHO the OO type of thinking doesn't stop at the front door where others
can see just the API. For my safety I apply it as far as possible, and I stop
when I end up with a class doing nothing but delegating the stuff it
could do itself.
just my two euro cents.
kind regards,
Jos
JosAHa at 2007-7-16 23:44:04 >
JosAH, I so feel the same!
I have become a strong believer in emergent design myself, and of course in applying OO principles down to the lowest level, regardless of where the client code API is. In a decent emergent design, most client code only needs to know about a few classes and interfaces at the top level, but for more advanced use and for unpredicted usages the classes and interfaces at any level will form a coherent and useful API, even if that wasn't an original requirement.
Lokoa at 2007-7-16 23:44:04 >
Reusability is the benefit most often claimed for OOP. However, that is sometimes disputed as being a large or primary benefit. The ability to maintain a program once written, the ability to do localized debugging, and the ability to do much larger parallel development efforts are all cited as more significant reasons to use an OOP language.
I don't know where the the comment about reusability came from, but I think the rest of the quote is more in the spirit of what I think is the chief benefit. Object-oriented programming maps well onto real world objects and matches our perception of the world.
This isn't true in all cases (that's what "reification" is all about), but objects like Ledger, Matrix, Window, Button, etc. give me an instant basis for understanding how the component might behave. There's a lot of value in that when you start dealing with a code base of thousands of lines.
Object-orientation helps to the degree that it facilitates decomposition of the problem.
%
I knew this first link and it's always looked highly "trollish" to me
http://www.geocities.com/tablizer/oopbad.htm
haven't read the other ones yet...
and yes, I DO think pure OOP is realistic (if "pure OOP" really means something), and I'm quite sure most academics do not fully grasp what it means (at least those I've been studying/working with)
Most computer science academics that I've come in contact with (admittedly not at hotbeds like Stanford, Carneigie Mellon, etc.) have gone through undergraduate and graduate school to earn Ph.D.s and then gone straight into the ivory tower without ever having earned a living as a programmer. I'm not sure that all of them can appreciate these things fully.
My opinion is that computer science is unique from other academic disciplines, because most of the innovation is being driven by industry, not academia. It's a more even split between the two in the field I came from, mechanical engineering.
Certainly one can argue that Stanford has driven a great deal of innovation (e.g., Sun, Google, etc.), but that's a top shelf school.
%
> > Why should anyone on the other side of that facade
> care?
>
> Maybe nobody on the sunny side of the facade cares,
> but you should
> care (the same counts for me too). I always design my
> classes on the
> shadow side of the facade having basically one thing
> in mind. For
> every single class I wonder: "can something/someone
> else do this?".
I'm not sure you understood what I meant. What I am saying is that designing everything out to the nth when the code can never be realisticly reused is not only a waste of time, it actually makes the code harder to use and maintain.
Just becausw two classes have similar functionality doesn't mean it makes sense to tie them together through delegation or extension. This is what happens when developers try to make every class resuable.
> > > Why should anyone on the other side of that facade care?
> >
> > Maybe nobody on the sunny side of the facade cares, but you should
> > care (the same counts for me too). I always design my classes on
> > the shadow side of the facade having basically one thing in mind.
> > For every single class I wonder: "can something/someone else do this?".
>
> I'm not sure you understood what I meant. What I am saying is that
> designing everything out to the nth when the code can never be
> realisticly reused is not only a waste of time, it actually makes the
> code harder to use and maintain.
>
> Just becausw two classes have similar functionality doesn't mean it
> makes sense to tie them together through delegation or extension.
> This is what happens when developers try to make every class
> resuable.
Yes I did understand what you meant: reusability is one thing, maintainability
is another issue. If two classes repeat (more or less) the same functionality,
they not just beg for refactorization because of the aesthetics or it all,
they should also be refactored because of the maintenance of it all (nobody
wants those duplicate functionalities liberally sprinkled all over a zillion classes).
Offering a nice and open/closed set of classes is not a maintenance
nightmare for the maintenance guy. An a-morph bunch of classes is.
Tying classes together by means of inheritance should be avoided
wherever and whenever realistic. OO is more than delivering proper
facades IMHO. both sides of the facade should be properly designed.
OO can be a big help here.
Only then, when everything has been designed/implemented as outlined,
one can start thinking of reusability of it all.
kind regards,
Jos
JosAHa at 2007-7-20 20:20:04 >
> > > > Why should anyone on the other side of that
> facade care?
> > >
> > > Maybe nobody on the sunny side of the facade
> cares, but you should
> > > care (the same counts for me too). I always
> design my classes on
> > > the shadow side of the facade having basically
> one thing in mind.
> > > For every single class I wonder: "can
> something/someone else do this?".
> >
> > I'm not sure you understood what I meant. What I
> am saying is that
> > designing everything out to the nth when the code
> can never be
> > realisticly reused is not only a waste of time, it
> actually makes the
> > code harder to use and maintain.
> >
> > Just becausw two classes have similar functionality
> doesn't mean it
> > makes sense to tie them together through delegation
> or extension.
> > This is what happens when developers try to make
> every class
> > resuable.
>
> Yes I did understand what you meant: reusability is
> one thing, maintainability
> is another issue. If two classes repeat (more or
> less) the same functionality,
> they not just beg for refactorization because of the
> aesthetics or it all,
> they should also be refactored because of the
> maintenance of it all (nobody
> wants those duplicate functionalities liberally
> sprinkled all over a zillion classes).
There are ways to approach this problem without trying to make every class reusable. Perhaps an example would help.
We send messages electronically to many different partners and organizations. Everyone we communicate with has specific needs that are particular to their organization. The original developers of the system tried to make this reusable by making the partner's specific requirements reuasable. That is, if one day, company B wants to use the same proprietary data structure that company A wanted, we'll be all set. Of course, this never happens. We ended up with dozens of 'reusable' pieces that no one else can use.
The approach that should have been taken was to accept that there were going to be things that were needed for A that B will never want of need and vice-versa and design a reusable component to deal with that non-reusable logic.
This is what I am getting at. There's always going to be stuff that's not reusable. The goal is to separate the chaff from the wheat and also make sure you can easily refactor all the mistakes that will be made. I can't count the number of maintenance nightmares that I have had to deal with because people did not consider that their design and implementation wasn't perfect in every way and might not satisfy a future need.
> Offering a nice and open/closed set of classes is not
> a maintenance
> nightmare for the maintenance guy. An a-morph bunch
> of classes is.
>
> Tying classes together by means of inheritance should
> be avoided
> wherever and whenever realistic. OO is more than
> delivering proper
> facades IMHO. both sides of the facade should be
> properly designed.
> OO can be a big help here.
Yes. I think we are really in agreement here. The idea is to layer things. What I have found though is that by using packages more effectively, I can build much moe sofisticated solutions with very clean interfaces. By hiding certain pieces and ensuring that they don't pollute the rest of the system, I can do things that I would never make part of a public interface but are still reusable through a clean abstraction layer.
The other thing is that we have lots of resuable components that just gather dust. The idea that something might be needed later was used throughout the system. That's all garbage now. Just a pain to deal with. It would have been better to hide that in a quick a dirty solution that wasn't public. Then if we need to expand that into a reusable piece, we can do so without affecting the rest of the system that is not changing.
