aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes OOP considered harmful (was: C. Date on UML book) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "OOP considered harmful (was: C. Date on UML book)" Watch "OOP considered harmful (was: C. Date on UML book)" New topic
Author

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

Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
Basic concepts in UML: a request for clarification
In case somebody doesn't know, he is Relational Databases guru. Mean article .
[ August 22, 2002: Message edited by: Mapraputa Is ]

Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1739
    
    2
Only glanced at the first couple paragraphs. Nothing new here: relational database dude getting all worked up because object orientation isn't ground in mathematics like relational database theory is (relational database stuff is apparently all based on set theory in mathematics) and key concepts are not as rigorously defined as he'd like or terms in OO don't necessarily have the same definitions as they do elsewhere.
I've read a little of Chris Date's stuff on relational databases (not recently, don't ask me to recall) and it can be quite illuminating. But when he ventures afield, it seems mostly to rant and criticize.
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
I was distracted with several other rants so I didn't answer this issue of paramount importance.
Only glanced at the first couple paragraphs.
:roll:
Nothing new here: relational database dude getting all worked up because object orientation isn't ground in mathematics like relational database theory is (relational database stuff is apparently all based on set theory in mathematics)
Certainly it is. "Set theory in mathematics" - set theory doesn't exist "in mathematics", it is a foundation of mathematics. All what math can say, can be expressed in terms of set and logic. Worse, all that *is* said in mathematics, *is* expressed via set theory and logic - in the final account. There is simply nothing besides it.
"because object orientation isn't grounded in mathematics" - there is nothing to be proud of. In what then is it grounded?
and key concepts are not as rigorously defined as he'd like
"What can be said at all can be said clearly" (Ludwig Wittgenstein).
"Design Patterns Explained" - great book, by the way! Maybe the best I read about OOP. So how is "object" defined?
"The traditional view of objects is that they are data with methods" - not good enough... "The best way to think about what object is, is to think of it as something with responsibilities" - "something with responsibilities"! *Now* it became clear!
or terms in OO don't necessarily have the same definitions as they do elsewhere.
"elsewhere" in this case means "predicate logic" or "set theory".
"Don't necessarily have the same definitions" - and why not? Please, show me benefits of vague language over strict definitions.
I've read a little of Chris Date's stuff on relational databases (not recently, don't ask me to recall) and it can be quite illuminating. But when he ventures afield, it seems mostly to rant and criticize.
The question is whether the critics is correct or not, right? If you see something you believe is Wrong, what are you supposed to do?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mapraputa Is:
Please, show me benefits of vague language over strict definitions.

I wonder wether every language without strict definitions really has to be vague. It seems to me that most often it isn't really hard to understand someone when you really try to listen, even if the language he is using doesn't have strict definitions. It might be surprising, but that is how human language seems to work for me most of the time.
[rant]
What I also wonder about betimes is the value of demanding a strict definition for all used terms - over trying to understand what is said by discussing the *issues* at hand, instead of the used terms.
[/rant]
Regards, Ilja


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
It seems to me that most often it isn't really hard to understand someone when you really try to listen
Unless language serves to obfuscate the subject - which is precisely the case with OOP.
OOP is one single bad idea that manifests itself on all levels, namely tight coupling (aggravated by ill-defined terminology).
What is the philosophy behind OOP:
1) everything is an object. An object is data and behavior
2) Objects form hierarchy
which is diametrically opposite to what relational model is about
1) data and code are separated
2) hierarchies (read: dependencies) are "normalized" - decoupled
The problem with OOP is that it leads to such complexity, that design guidelines are needed - to save OOP from itself.
"Design Patterns Explained", p. 117:
"in effect many design patterns use incapsulation to create layers between objects - enabling the designer to change things on different sides of the layers without adversely affecting the other side. This promotes loose-coupling between the sides."
Show me how is it different from what Relational Model called "normalization"?
Well, one difference is that there is a well-defined mechanism to implement normalization, and implement it rigoriously, so that once you done with it, *all* "what varies" is "encapsulated" , there is no need for Great Intellectual Quest any more That's why there is no need for "patterns" in RM.
In contrast, OOP is all about finding "what varies", giving each particular case its own name and calling it "pattern".

"Design Patterns Explained", p. 71
"Design patterns are part of cutting edge of object-oriented technology. Object-oriented analysis tools, books and seminars are incorporating design patterns. Study groups on design patterns abound, It is often suggested that people learn design patterns only after they have mastered basic object-oriented skills. I have found that the opposite is true. Learning design patterns early in the learning of object-oriented skills greatly helps to improve understanding of object-oriented analysis and design"
I would say to circumvent "object-oriented analysis and design" and bring it back to sanity
Rudy Dakota
Ranch Hand

Joined: Jul 27, 2002
Posts: 54
Hi there,
With respect to Date's work, Michael wrote:
But when he ventures afield, it seems mostly to rant and criticize.
I don't think this is entirely true. A lot of the database writings by Date are comparable critisisms of vague language.
At the end of the day, Date is very rigorous where it comes to terminology and definitions. He applies that to his own field, and he is not shy in acknowledging mistakes he made. This often results in very clear theoretical texts. Mind you: theoretical texts that often are very relevant for day-to-day work.
What he does in the UML article is simply checking another field against the same high standards he applies to database theory. His conclusion, and he is not alone in that, is that there is no trace of a clear, precise and shared theory behind object orientation. Not something to be proud of, or something to dismiss as ranting.
If anything, this kind of critcism should stimulate discussions on the foundation of object orientation. I am sure that is what Date would also like to achieve. He contributes what he is best in: an analysis of the definitions used.
If only I had half the rigorous logic Date brings into play (and a bit more knowledge of object orientation), I would try and contribute to the discussion on theoretical foundations in a positiev way. I would certainly hope others, better qualified than I am, will take this up.
Good riding,
Rudy
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
I would certainly hope others, better qualified than I am, will take this up.
I would also hope. Meanwhile...

"OOP demystified" Part 1. Everything is an object. An object is data and behavior
"Design Patterns Explained", p. 117:
"Suppose I am working on a project that models different characteristics of animals. My requirements are the following:
1) each type of animal can have a different number of legs <...>
2) each type of animal can have a different type of movement <...>
[two approaches are suggested]
Unfortunately both of these approaches have problems <...>
"A third possibility exists: have the Animal class contain an object that has the appropriate movement behavior"
diagram:
class: Animal <---- class: AnimalMovement
                                                 /\
                                   AmimalFly AnimalWalk
[end of quote]
Think about it: first we combine (for unknown reason) data and behavior in one object Animal. Then we, naturally, discover that this is a stupid thing to do in the first place, because tight coupling leads to inflexibility. Now we need to "encapsulate" variations in behavior and how can we do that if "everything is an object"? Right - apply a "pattern" and have a special class (two actually) that "implement" behavior!
So instead of simple non-OOP
[data] [behavior]
we have:
["data + behavior" that "implements" only data] - contains ["data + behavior" that implement only behavior] extended by two other "data&behavior" that implement only behavior.
"Design Patterns Explained":
"This may seem like overkill at first. However, it's nothing more than an Animal containing an object that contains the movement behavior of the Animal"
- surely this is not overkill, it only "seem like overkill"!
[ August 22, 2002: Message edited by: Mapraputa Is ]
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1739
    
    2
Take a trip to a world where data is separate from behavior.
A table with the following structure is in < scratches head > at least the third normal form. (?) It stores the start and end date of DB training classes.
training_class
--------------
id (varchar(4)), primary key
start_dt (date), not nullable
end_dt (date), nullable
Table contents
id start_dt end_dt
---- ----------- -----------
AAAA 05-AUG-2002 09-AUG-2002
AAAB 12-AUG-2002 16-AUG-2002
AAAC 23-AUG-2002 19-AUG-2002
AAAD 26-AUG-2002 30-AUG-2002
Could this happen in an OO world where any self-respecting DateRange object knows (has behavior, has a method) how to check to make sure the end date of a range does not preceed the start date?
[ August 22, 2002: Message edited by: Michael Matola ]
Ron Newman
Ranch Hand

Joined: Jun 06, 2002
Posts: 1056
I'm a rank novice when it comes to databases, but isn't that what "constraints" are for?


Ron Newman - SCJP 1.2 (100%, 7 August 2002)
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1739
    
    2
Originally posted by Ron Newman:
...but isn't that what "constraints" are for?

Those kind of constraints are outside the relational model, I believe. (Somebody please stop me before I end up making myself look very foolish.) And it's the relational model that Map's pitted against OO.
The constraints that are part of the relational model are entity integrity and relational integrity. My proposed table and data meet the standard of entity integrity. Referential integrity isn't relevant to a table in isolation (there's no foreign key defined).
My point (which seems very flimsy by now) is that in this particular case, this is as far as the relational model gets us: the integrity constraints have been met and our table is reasonably normalized, but we've allow bad data to be created.
The kind of data constraint or business rule to enforce the start date/end date sillyness is what I'm viewing as a behavior (even though some database products may allow us to conveniently declare and enforce this rule). With OO, you don't have that separation. A DateRange object, for example, would not allow iself to get into the inconsistent state that I've put id AAAC in.
Michael Matola
whippersnapper
Ranch Hand

Joined: Mar 25, 2001
Posts: 1739
    
    2
Originally posted by Rudy Dakota:

At the end of the day, Date is very rigorous where it comes to terminology and definitions. He applies that to his own field, and he is not shy in acknowledging mistakes he made. This often results in very clear theoretical texts. Mind you: theoretical texts that often are very relevant for day-to-day work.

Anything in particular you'd recommend?
[ August 22, 2002: Message edited by: Michael Matola ]
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
"PREDICATES: A BRIEF TUTORIAL" by C. J. Date
"This three-part article is intended as a tutorial on the crucial notion of integrity constraints (which I'll usually abbreviate to just constraints) and the associated and equally crucial notion of predicates. <...> These notions are absolutely fundamental, and yet they don't seem to be very well understood in the database community at large.
<...>
Of course, I'm sure most readers will agree that the integrity constraint concept is easy enough to understand at an intuitive level; intuitively, a constraint is just a conditional expression -- also known as a boolean, truth-valued, or logical expression -- that's required to evaluate to true. Here are a few simple examples <...>:
1. Every supplier status value is in the range 1 to 100 inclusive.
2. Every supplier in London has status 20.
3. If there are any parts at all, at least one of them is blue.
4. No two distinct suppliers have the same supplier number.
5. Every shipment involves an existing supplier.
6. No supplier with status less than 20 supplies any part in a quantity greater than 500.
And so on.
<...>
I'd like to go further and offer evidence that suggests that a fair number of database professionals, including in particular authors of textbooks, don't seem even to appreciate the fundamental nature and importance of integrity in a database context. A quick and admittedly not very scientific survey of a whole shelfload of database textbooks -- 37 in all, including essentially all of the best-known ones -- reveals the following:

  • Only one book had an entire chapter devoted to the topic of integrity -- and even there I have severe reservations about the quality of the treatment.
  • Most of the books examined didn't even mention integrity in a chapter title at all,
  • I couldn't find a good explanation or definition of the concept, let alone the kind of emphasis I think the concept deserves, in any of the books at all.


  • :roll:
    [ August 22, 2002: Message edited by: Mapraputa Is ]
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    Originally posted by Michael Matola:
    Could this happen in an OO world?

    Actually, worse things happen in OOP word.
    Joshua Bloch. "Effective Java", p.26
    Item 7. Obey the general contract when overriding equals
    When you override the equals method, you must adhere to its general contract. Here is the contract, copied from the specification for java.lang.Object:
    * The <code>equals</code> method implements an equivalence relation:
    *
      *
    • It is reflexive: for any reference value <code>x</code>,

    • * <code>x.equals(x)</code> should return <code>true</code>.
      *
    • It is symmetric: for any reference values <code>x</code> and

    • * <code>y</code>, <code>x.equals(y)</code> should return
      * <code>true</code> if and only if <code>y.equals(x)</code> returns
      * <code>true</code>.
      *
    • It is transitive: for any reference values <code>x</code>,

    • * <code>y</code>, and <code>z</code>, if <code>x.equals(y)</code>
      * returns <code>true</code> and <code>y.equals(z)</code> returns
      * <code>true</code>, then <code>x.equals(z)</code> should return
      * <code>true</code>.
      *
    • It is consistent: for any reference values <code>x</code>

    • * and <code>y</code>, multiple invocations of x.equals(y)
      * consistently return <code>true</code> or consistently return
      * <code>false</code>, provided no information used in
      * <code>equals</code> comparisons on the object is modified.
      *
    • For any non-null reference value <code>x</code>,

    • * <code>x.equals(null)</code> should return <code>false</code>.
      *
      Unless you are mathematically inclined, this might look a bit scary, but do not ignore it! If you violate it, you may well find that your program behaves erratically or crashes, and it can be very difficult to pin down the source of the failure.
      <,,,>
      p.30
      So what is the solution? It turnes out (sic! -Map) that this is a fundamental problem of equivalence relations in object-oreinted languages. There is simply no way to extend an instantiable class and add an aspect while preserving the equals contract
      <...>
      The equals implementation for java.sql.Timestamp does violate symmetry and can cause erratic behavior if Timestamp is and Data objects are used in the same collection or are otherwise intermixed."

      Now: if creators of Java make this kind of mistake, what would you expected from an average developer, who, as Michael Matola demonstrated, is too lazy to check if "end date of a range preceed the start date"?
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    Yep, that's a rant. It makes the point the OOP isn't strictly defined, but that's why there's more than one OO language! The Java Language Specification is concrete, partially because it defines things in terms of implementation. If there's a Smalltalk Language Specification, it probably does the same sort of thing.
    OOP itself is only an approach, not a self-contained solution. It mixes the well-defined concept of an Abstract Data Type with the poorly defined concept of polymorphism. Polymorphism serves buisness purposes: sure it allows you to put the system in a bizarre self-contradictory state that nobody is prepared for, but as long as you don't actively try to sabatoge your own program it will be infinately extensable while remaining easy to conceptualize and maintain.
    This highlights the difference between the mathmatically rigorous approach and the practical one. A cashier doesn't need to know number theory to count out change for someone.
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    It makes the point the OOP isn't strictly defined, but that's why there's more than one OO language!
    Otherwise, 2 + 2= 45 in one language and 138 an another? Is this what you are trying to advocate?
    If OOP isn't strictly defined, it's not necessarily there is more than one OO language, it can be that there is only one, ill-defined language.
    The Java Language Specification is concrete, partially because it defines things in terms of implementation.
    Well, if it doesn't know any better, then yes, the only way to specify ANYTHING is to "define things in terms of implementation".
    2 + 2 =56 because this is how I implement it
    This highlights the difference between the mathmatically rigorous approach and the practical one. A cashier doesn't need to know number theory to count out change for someone.
    "First, there is a failure to appreciate the difference between working from general principles and what I call the "cookbook" (or "recipe") approach. It is sad that in this day and age -- and certainly in this society, where efficiency is one of the fundamental values -- there is a need to defend the general approach against the case by case approach. Any situation or crisis that practitioners encounter can be a specific instance of some general principle from theory. If you know the general principle, you can apply it to many of your specific instances; if you don't, you will constantly need recipes to resolve what are essentially similar problems. Which is more practical?"
    http://www.pgro.uk7.net/fp3a1.htm
    [ August 23, 2002: Message edited by: Mapraputa Is ]
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    This highlights the difference between the mathmatically rigorous approach and the practical one. A cashier doesn't need to know number theory to count out change for someone.
    This is a very important point of disagreement. Perhaps the most important point of the whole discussion.
    Frankly, I forgot why did I took "21 Century Synonym And Antonym Finder" to look for antonyms of "practical" - were I looking for a word "theoretical" with obertones of
    1) rigoriously defined as opposed to ill-defined
    2) well-thought in a systematic way as opposed to ad-hoc approach
    3) logically consistent as opposed to sloppy and vague definitions???
    ANYway... The two meaning of "practical" I founds are:
    1) realistic, useful with antonyms: impossible, impractical, unfeasible, unrealistic, unserviceable, unworkable, useless, worthless.
    Um... thank you.
    2) experienced, proficient
    antonyms: incapable, inefficient, inexperienced, unseasoned, unskilled, useless.
    Indeed so...
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    It makes the point the OOP isn't strictly defined, but that's why there's more than one OO language!
    Otherwise, 2 + 2= 45 in one language and 138 an another? Is this what you are trying to advocate?

    Well, *there are* mathematical entities for which "+" is defined so that 2 + 2 = 1 (Z/3Z, an additive cyclic group of order 3, for example).
    OTOH, I don't know an OO language where that would be the default definition. So, what is your point? What is the *real* issue with current OO languages?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    [QB"A third possibility exists: have the Animal class contain an object that has the appropriate movement behavior"
    diagram:
    class: Animal <---- class: AnimalMovement
                                                     /\
                                       AmimalFly AnimalWalk
    [end of quote]
    Think about it: first we combine (for unknown reason) data and behavior in one object Animal. Then we, naturally, discover that this is a stupid thing to do in the first place, because tight coupling leads to inflexibility. Now we need to "encapsulate" variations in behavior and how can we do that if "everything is an object"? Right - apply a "pattern" and have a special class (two actually) that "implement" behavior!
    So instead of simple non-OOP
    [data] [behavior]
    we have:
    ["data + behavior" that "implements" only data] - contains ["data + behavior" that implement only behavior] extended by two other "data&behavior" that implement only behavior.
    [/QB]

    Yeah, you really seem to be confused...
    What you *should* have in a well crafted OO design (but what possibly isn't very clear from the example as presented), is
    - an Animal class that implements *data and behaviour* that is common to animals besides their specific movement strategies
    - a Movement baseclass implementing *data and behaviour* that is common to all movement strategies (e.g. current direction and how to change it)
    - and specific subclasses of Movement which implement *data and behaviour* that is specific to that movement strategy (e.g. current flapping frequency and how to do a nose dive)
    So, what do you think about that?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    [b]Show me how is it different from what Relational Model called "normalization"?
    Well, one difference is that there is a well-defined mechanism to implement normalization, and implement it rigoriously, so that once you done with it, *all* "what varies" is "encapsulated" , there is no need for Great Intellectual Quest any more That's why there is no need for "patterns" in RM.

    Well, relational normalization does only normalize data, so it seems to me. A big part of the OOP movement is the goal to also normalize behaviour. You are right that till now there isn't a mechanical way to do that, so we have to resort to patterns, refactorings and other design principles to guide us until we find one (if there even *is* one to find).
    Nevertheless I find OO principles to be very helpfull when it comes to structure behaviour so that every idea is expressed "once and only once". And it really isn't *that* hard to understand, once you started to open your mind to it and accepted that currently it is more of a craft than of a science.
    Thomas Paul
    mister krabs
    Ranch Hand

    Joined: May 05, 2000
    Posts: 13974
    If all my programs were simply data and not business rules, then life would be much simpler. Date's rant is about UML, not OOP. He is quite correct that UML, which claims to be a strict modeling language, lacks clarity. That is a problem that could be addressed. Why can't UML properly define what an object is? I get the impression that the authors of UML simply are trying to make UML usable by everyone for every situation.
    As for OOP, the idea is to create classes that understand themselves. Classes should contain the data and behavior that they need to do their job. At the same time, classes need to be flexible enough so that new classes can be added into the hierarchy with minimal work. Let's face it, in the last 40 years we programmers have tried all different manners of coding and have found serious problems with each one. OO requires a lot of up-front design but that is supposed to make it easier to maintain and enhance. The problem, of course, is that there are not many good up front designers and most customers don't like the idea of spending money on design.


    Associate Instructor - Hofstra University
    Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Thomas Paul:
    He is quite correct that UML, which claims to be a strict modeling language, lacks clarity. That is a problem that could be addressed. Why can't UML properly define what an object is?

    I don't know wether UML claims to be a strict modeling language, and I don't care. For me the value of UML is in aiding communication with people, preferable standing on a white board or scribbling on paper. It doesn't need to be strict for that - in fact I don't mind bending the rules if it helps in the specific situation.
    OO requires a lot of up-front design but that is supposed to make it easier to maintain and enhance.

    OO doesn't have to require a lot of up-front design. In fact, the strong decoupling that is enabled by sound OO principles enables techniques which make less up-front design necessary, IME.
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    It is sad that in this day and age -- and certainly in this society, where efficiency is one of the fundamental values -- there is a need to defend the general approach against the case by case approach.

    I didn't bother following the link, but I must say that this is a genuinely dumb statement. Should the carpenter throw out his hammer because it might not be the best tool for the next job? Should the mathmatician throw out calculus because there are new problems to solve? I believe, Map, I've read posts where you discuss generalization being at the center of intellegence. Since it's become obvious that you're trolling, I won't bother searching for them.
    Rudy Dakota
    Ranch Hand

    Joined: Jul 27, 2002
    Posts: 54
    Hi there,
    Michael asked me:
    Anything in particular you'd recommend?

    Well, there is the textbook An introduction to Database Systems by many considered the bible of the RDBMS world. After reading, or indeed studying that one should know his way about databases.
    There is also perhaps the most practical of his work I know, a number of articles on three-valued logic and null values. Unfortunately I don't have the bundle where I read those at hand (it 's in the office), but I can give a reference next week.
    Good riding,
    Rudy.
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    So, what do you think about that?
    1 An Animal class

    What if "something with responsibilities" is *not only* Animal? (admittedly contrived example: "people"). There is no such thing as multiple inheritance in Java, once inherited from "ape" you cannot inherit from your parents
    How about "Animal" interface instead?
    that implements *data and behaviur* that is common to animals besides their specific movement strategies
    In other words specific kinds of animals inherit it?
    Joshua Bloch. "Effective Java" p.73
    Item 14. Favor composition over inheritance.
    "Unlike method invocation, inheritance breaks encapsulation.
    <...>
    Luckily, there is a way to avoid all of the problems described earlier. Instead of extending an existing class, give your new class a private field that references an instance of the existing class. This design is called composition because the existing class becomes a component of the new one. Each instance method in the new class invokes the corresponding method of the contained instance of the existing class and returns the result. This is known as forwarding, and the methods in the new class are known as forwarding methods. The resulting class will be rock solid, with no dependencies on the implementation details of the existing class."
    How is this conceptually different from simply calling a non-OOP method? And before I forget, remind me, what was called "redundance" before OOP?
    - a Movement baseclass implementing *data and behaviour* that is common to all movement strategies (e.g. current direction and how to change it)
    - and specific subclasses of Movement which implement *data and behaviour* that is specific to that movement strategy (e.g. current flapping frequency and how to do a nose dive)

    This time interfaces without doubt, otherwise our ducks will never fly...
    So how do we inherit data with interfaces? The same Joshua Bloch advises not to:
    Item 17. Use interfaces only to define types.
    "In summary, interfaces should be used only to define types. They should not be used to export constants"
    Are you aware of how inheritance of interface's constant is implemented? They are simply get copied to your class. (Remind me, what was called "redundance" before OOP?) Now what happens if somebody changes a constant and recompile an interface? Your classes have an outdated, out of synch copy. Relational model was specifically created to prevent this craziness. This is a subtle corner of Java, one of many that unnecessarily complicate mastering of the language.
    Ok, now how we can inherit behavior with interfaces? Fortunately, here we are safe, OOP doesn't fail us here. Since all methods in an interface are abstract, we cannot inherit behavior.
    So in the final account it all boils down to simple method calls?
    Let's start all over again: what is the point of combining data and behavior and call it "object"?
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    I didn't bother following the link, but I must say that this is a genuinely dumb statement.
    Well, this is partly the problem with "C.Date - OO people" communication. Database people read a book and write response. OO people :
    "Only glanced at the first couple paragraphs..."
    "I didn't bother following the link..."
    Should the carpenter throw out his hammer because it might not be the best tool for the
    next job?

    Let's restate the question: Should the carpenter throw out the best tool for the next job because he has his hammer? And by chance, you do not refer to "To a Hammer Everything Looks Like Nails" proverb, do you?
    Map, I've read posts where you discuss generalization being at the center of intellegence. Since it's become obvious that you're trolling, I won't bother searching for them.
    Trolling?
    If you mean my anti-OOP rant, I overstressed here and there a little, partly for the sake of public entertainment. I guess, I should tone down, or I will only alienate people... But since your conjecture is juxtaposed with your opinion about "genuinely dumb statement", I worry that you may well refer to my agreement with Fabian Pascal. Here I am 100% serious, no provocations intended. I am surprised at your reaction, for me its truth is obvious and self-evident, and for this reason I won't bother talking to you anymore
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    If all my programs were simply data and not business rules, then life would be much simpler.
    Ah, this is exactly the misunderstanding Date&Pascal are trying to debunk!
    "Experience has taught that it is neither cost-effective, nor reliable to implement the gamut of data management functions -- data definition, integrity and manipulation, concurrency control, physical storage and access, query optimization, security -- in each and every application program, let alone modify programs when data change. That is why we migrated to databases, whereby those functions are implemented centrally in a DBMS for all application programs to share, leaving only application functions -- communication with users and presentation of results -- in programs. This is exactly what data independence is all about, and object-orientation does nothing to obviate its necessity."
    "To a hammer, everything looks like a nail: Part I"
    "Quote: "it seems like a false choice to me to try to decide between objects and data - what would the object methods process if not data? Where is the data persisted and stored when it is not being processed? A relational database entity is an object without methods. When the methods are added by way of stored procedures or other functions, you are half way to object-relational technology. Of course, for certain kinds of real-time embedded systems in airplanes, cell phones or complex processes in power plants or pipelines, the importance of data storage is significantly less."
    Nonsense. Agosta understands neither what a data model is, nor the relational data model specifically (see Date's "Models, Models Everywhere, Nor Any Time to Think" and my "Something to Call One's Own"). What is more, his argument is as fuzzy as are object concepts. There are "methods available for relational entities": every domain comes with operators and the relational operations (restrict, project, join, union and so on) rely on them for manipulating data in tables. All an application programmer needs to do is to invoke these operations in applications, rather than write his/her own (as is necessary with an ODBMS). The use of stored procedures should be avoided for a variety of reasons, an important one being the superiority of declarative integrity support over a procedural approach.
    As to object-extensions to relational databases, I quote from Date's and Darwen's book The Third Manifesto: ... "the relational model needs no extension, no correction, no subsumption -- and above all, no perversion! -- in order for it to ... support [those few desirable] features that are commonly regarded as aspects of object-orientation, [because they are] orthogonal to (i.e., independent of] the relational model."
    "Oh, Oh not OO Again" by Fabian Pascal
    As for OOP, the idea is to create classes that understand themselves.
    Not sure what "understand themselves" means, knows its type? (which means interface, Joshua Bloch, "Effective Java" p. 156.
    "Item 34. Refer to objects by their interfaces.
    If appropriate interface exist, parameters, return values, variables, and fields should all be declared using interface types"
    Ok, now about interfaces - I am confused again.
    Since interfaces are advised to be simple sets of method signatures, what does that mean that class X implements interface Y, or in other words X is of type Y?
    It mean that an object X has all the methods declared in an interface. But all these methods are written in the class' code, "implements" declaration is simply a tautology. Otherwise we could as well write
    class X implements Y declares (list all variables here) {}
    - but we do not for obvious reasons
    So first we are saying what was implicitely already said, yet later we have to perform cast (tell what the type is) when fetching our types out of collections. Is this what you mean by "classes that understand themselves"?
    Date's rant is about UML, not OOP.
    This particular rant yes, but he has others, specially targeted at OOP
    Like this one examining problems with OOP inheritance model.
    TYPE INHERITANCE: IS A CIRCLE AN ELLIPSE?

    OO requires a lot of up-front design but that is supposed to make it easier to maintain and enhance. The problem, of course, is that there are not many good up front designers and most customers don't like the idea of spending money on design.
    This is the point I was trying to make. There is always limited intelligence in every society, and OOP for my taste requires unrealistic amounts of it (and for no good reason!). Now looking back at classes I took in college here, our instructors simply did not understand OOP. One of them for example, honestly admitted lack of understanding AWT design: "looks weird to me" What then would you expect from students?
    [ August 23, 2002: Message edited by: Mapraputa Is ]
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    Alan Shalloway, author of "Design Patterns Explained" (bold face is mine):
    "In many ways, this book is a retelling of my personal experience learning design patterns. Prior to studying design patterns. I considered myself to be reasonably expert in object-oriented analisys and design. My track record had included several fairly impressive designs and implementations in many industries <...>
    Now looking back, I see that I really did not understand the full capabilities of object-oriented design, even though I was doing things the way the experts advised. It wasn't until I began to learn design patterns that my object-oriented design abilities expanded and deepened.
    I began studying design patterns in 1996. I was a C++/object-oriented design mentor at a large aerospace company in the northwest. Several people asked me to lead a design pattern study group.
    <...>
    I was working on a project as a mentor in object-oriented design and was asked to create a high-level design for the project. <...>
    I had developed a design based on my normal approach of data abstraction. Unfortunately, it was very clear this was not going to be a good design.
    <...>
    Two hours later, after applying every design technique I knew, I was no better off. My design was essentially the same. What was most frustrating was I knew there was a better design. I just couldn't see it.
    <...>
    I took a break... I had gotten an insight that changed my view of design patterns: rather than using patters as individual items, use the design patterns together."
    The book is very good, by the way.
    Do not you think, when even leaders of industry cannot get OOP, something is wrong with it?
    How useful is the methodology if people with track of "several fairly impressive designs and implementations in many industries" cannot ger it? What is use of patterns if people who "lead a design pattern study group" still cannot get them? Is this what you call "practical"?
    [ August 24, 2002: Message edited by: Mapraputa Is ]
    Frank Carver
    Sheriff

    Joined: Jan 07, 1999
    Posts: 6920
    To add further fuel to this fire, someone recently pointed me to the following letter by Edsger Dijkstra.


    Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Frank Carver:
    To add further fuel to this fire, someone recently pointed me to the following letter by Edsger Dijkstra.

    Nice link, thanks!
    As I scanned over it (I don't like reading long texts on the monitor - the printer is still busy...), I found it to be very enlightening.
    One thing that catched my eye was at the bottom of page 8 et seq. There he says that the feedback loop cannot be closed instead for the simplest systems. But I think that is exactly what the Agile Movement is about: closing the feedback loop.
    Well, of course this article is twenty years old - and we all know what such a time span means to our industry. Would be interesting to know what he would say today about it...
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    Do not you think, when even leaders of industry cannot get OOP, something is wrong with it?
    How useful is the methodology if people with track of "several fairly impressive designs and implementations in many industries" cannot ger it? What is use of patterns if people who "lead a design pattern study group" still cannot get them? Is this what you call "practical"?

    Do you think the author didn't find it to be usefull until he "finally got it"? Do you think he stopped learning about OOP after that point?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    Date's rant is about UML, not OOP.
    This particular rant yes, but he has others, specially targeted at OOP
    Like this one examining problems with OOP inheritance model.
    TYPE INHERITANCE: IS A CIRCLE AN ELLIPSE?

    That is not a problem with the OOP inheritance model, but with the misunderstanding that subtyping has to model an "IS A" relationship in the real world - which is in fact nothing more than a simple heuristic.

    This is the point I was trying to make. There is always limited intelligence in every society, and OOP for my taste requires unrealistic amounts of it (and for no good reason!).

    Perhaps you should try Squeak, which is a Smalltalk implementations for kids... :roll:
    Now looking back at classes I took in college here, our instructors simply did not understand OOP. One of them for example, honestly admitted lack of understanding AWT design: "looks weird to me" What then would you expect from students?

    I would expect them to not gain much from OOP until they find better sources for learning it. I would expect the more intelligent to *actively look* for better sources.
    Isn't it a well known fact that even the average heads don't become teachers because those don't get paid enough?
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    So, what do you think about that?
    1 An Animal class

    What if "something with responsibilities" is *not only* Animal? (admittedly contrived example: "people"). There is no such thing as multiple inheritance in Java, once inherited from "ape" you cannot inherit from your parents
    How about "Animal" interface instead?

    There were no "people" or "parents" mentioned in the requirements, and I am rather reluctant to over-engineering - especially as it isn't that hard to refactor to an interface based solution later on. But if you like to, yes it could be an interface. I don't think it isn't that relevant to the example. Now, back to the issue?

    that implements *data and behaviur* that is common to animals besides their specific movement strategies
    In other words specific kinds of animals inherit it?

    Well, in the example it was only required that the animal object knows the number of legs, iirc. I don't think we need subclasses for that.

    Joshua Bloch. "Effective Java" p.73
    Item 14. Favor composition over inheritance.
    "Unlike method invocation, inheritance breaks encapsulation.
    <...>
    Luckily, there is a way to avoid all of the problems described earlier. Instead of extending an existing class, give your new class a private field that references an instance of the existing class. This design is called composition because the existing class becomes a component of the new one. Each instance method in the new class invokes the corresponding method of the contained instance of the existing class and returns the result. This is known as forwarding, and the methods in the new class are known as forwarding methods. The resulting class will be rock solid, with no dependencies on the implementation details of the existing class."
    How is this conceptually different from simply calling a non-OOP method?

    The difference is that the method call is polymorphic - you can change the fact which actual method is called without having to touch the caller. It better decouples the caller from the callee.
    That is exactly what is happening in the example: the Animal class doesn't need to know about the actual implementors of the Movement interface. It just polymorphically executes the movement it got assigned.
    And before I forget, remind me, what was called "redundance" before OOP?

    I don't think I understand this question.

    - a Movement baseclass implementing *data and behaviour* that is common to all movement strategies (e.g. current direction and how to change it)
    - and specific subclasses of Movement which implement *data and behaviour* that is specific to that movement strategy (e.g. current flapping frequency and how to do a nose dive)

    This time interfaces without doubt, otherwise our ducks will never fly...

    No, classes, without doubt. You couldn't define behaviour or dynamic data in interfaces.

    Let's start all over again: what is the point of combining data and behavior and call it "object"?

    There wouldn't be much of a point about it if you didn't hide the data. Once you make sure that only the behaviour of the object itself can change its state (data), it gets much easier to assure that its state always is consistent.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Mapraputa Is:
    I didn't bother following the link, but I must say that this is a genuinely dumb statement.
    Well, this is partly the problem with "C.Date - OO people" communication. Database people read a book and write response. OO people :
    "Only glanced at the first couple paragraphs..."
    "I didn't bother following the link..."

    Is such generalization typical for non-OO people, or is it just you?
    BTW, did you bother following one of the links I posted (the one regarding OO being syntax for jump tables comes to mind)? I don't remember seing a comment from you...
    If you mean my anti-OOP rant, I overstressed here and there a little, partly for the sake of public entertainment.

    Perhaps it isn't so funny to the people who try to help you. But perhaps you really *don't want* to be helped? Perhaps you should make more clear wether you are really interested in the answers to your questions...
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    (copied from another thread for smoother discussion
    )
    Here is more of Joshua Bloch:
    "It is safe to use inheritance within a package, where the subclass and the superclass implementation are under the control of the same programmers. It is also safe to use inheritance when extending classes specifically designed and documented for extension.
    The are a number of obvious violations of this principle in the java Platform libraries. For example, a stack is not a vector, so Stack should not extend Vector. Similarly, a property list is not a hash table so Properties should not extend Hashtable. In both cases, composition would have been appropriate.
    If you use inheritance where composition is appropriate, you needlessly expose implementation details. The resulting API ties you to the original implementation, forever limiting the performance of your class. More seriously, by exposing the internals you let the client access them directly. At the very last, this can lead to confusing semantics. ... More seriously, the client may be able to corrupt invariants of the subclass by modifying the superclass directly. In the case of Properties, the designer intended that only strings be allowed as keys and values, but direct access to the underlying Hashtable allows this invariant to be violated. Once this invariant is violated, it si no longer possible to use other part of the Properties API (load and store). By the time this problem was discovered, it was too late to correct it because clients depended on the use of nonstring keys and values."
    Then he went on to explain all the power of wrappers.
    "Besides being robust, this design is extremely flexible."
    "The disadvantages of wrapper classes are few. One caveat is that wrapper classes are not suited for use in callback frameworks, wherein objects pass self-references to other objects for later invocations ("callbacks"). Because the wrapped object doesn't know of its wrapper, it passes a reference to itself (this) and callbacks elude the wrapper. This is known as the SELF problem."
    "To summarize, inheritance is powereful, but it is problematic because it violates encapsulation. It is appropriate only when a genuine subtype relationship exists between the subclass and the superclass. Even then, inheritance may lead to fragility if the subclass is in a different package from the superclass and the superclass is not designed for extension. To avoid this fragility, use composition and forwarding instead of inheritance, especially if an appropriate interface to implement a wrapper class exists. Not only are wrapper classes more robust than subclasses, they are also more powerful."
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    Is such generalization typical for non-OO people, or is it just you?
    Just me
    (I was tempted to say "typical for non-OO people", but this would be generalization )
    I did read it, thanks for the link, it raised too important issue and I needed some time to think.
    The post title is "Does OOP assume something
    about human nature?" and I totally agree that OOP is unnatural for human thought - nothing to argue with here.
    Jump tables, I was close to this idea yesterday, thanks for the link, it made the point clear. "It's just fancy syntax wrapped around jump tables"... We know by now that it's wiser to yield burden of data maintenance to databases, so the only real value OOP brings is code management. Methods are grouped in interfaces, which are nothing but tables, so "jump tables" are damn close to the target.
    But looking at all complexity they introduce, all those classes/inner classes/abstract classes/anonymous classes/overriden methods/constructors default or not -- they unnecessarily expose implementations details to programmer. With relational model you define your constraints in declarative form and you do not worry about data updating any more - all update operations have to perform check for you at every deletion/insertion/change whatever. With OOP you have to go into implementation details.
    Douglas Dunn. "Java Rules". p. 152-153.
    "The strange thing about the fact that this is polymorphic is overridden instance methods and constructors. Constructors are not members of a class and not, therefore, inherited by subclasses. Nor are overridden instance methods. Nevertherless, the this keyword is polymorphic in both. <...> the reason for this is explained in detail in the next section. It is not hard to uderstand what is happening if you know how super is implemented in a Java compiler".
    Of course, I am eager to know how super is implemented in a Java compiler". And even after all this, there are still so many points OOP can (and does!) fail you, so I would improve the definition as follow:
    "OOPLS: badly designed, unreliable, fragile, overcomplicated, unnecessarily exposing implementations details jump tables managers"
    [ August 24, 2002: Message edited by: Mapraputa Is ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Map, I find it to be very tedious to reply time and again to quotes from books which often seem to be taken out of context. I think there is a reason that the authors wrote a whole book about the subject and it probably won't amount to much to interprete each statement as if it was standing for its own.
    I think this discussion could be much more constructive if we could talk about *your* *experience* regarding OOP - what projects you did and where OOP failed *you*. Currently it is my impression that you *don't have* any experience.
    Perhaps if you had, you would more feel like me: I don't think of myself as an OO guy (anymore) - nor as a non-OO guy. I am simply a programmer who is glad to know OOP to be in his bag of tricks. I am aware of (most of) the pitfalls of it, of the marketing hype surrounding it and of its true values, I think. And I know that I will never stop learning more about it (so I hope!) - besides other development paradigms, of course. Especially I am fully aware of Java being far from being the perfect implementation of an OO language - which is a pity, because my current employ wouldn't pay me for programming in Smalltalk (and Lisp doesn't seem to be an option, likewise)... :roll:
    I am tired of this entirely theoretical "us versus them" debate. I quit.
    PS: I am sorry for the harsh tone of my last posts - I think I already was feeling tired and should have quitted earlier. Please accept my apologies.
    [ August 25, 2002: Message edited by: Ilja Preuss ]
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    Especially I am fully aware of Java being far from being the perfect implementation of an OO language
    Then what we were talking about all this time?
    I think, it's the same like when Joshua Bloch is saying more about when not to use inheritance, assuming general awareness of its virtues. Likewise, I was assuming general fondness of OOP so was talking more about its problems. So you overreacted on my overreacting, which in turn, provokes my further overreacting... Um. The thread does go less-than-constructive lately, yes. I was really intended to investigate if there are alternatives to OOP in code reuse, less complex than full-blown OOP.
    This nice paper, for example, suggests extending "host language" (C in current implementation) with macro facilities, so one could "hide" chunks of code behind a macro. (they plan on implementing this for Java also). And in this model macros aren't just shortcuts, you are allowed to use elements from parsing tree, so you can write (I am reusing my RegEx example from another thread):
    syntax <stm> while (<exp E1> matches <exp E2>) {
    <stm S> } ; ::=
    here <exp> means any expression, and <stm> any statement, so we can write
    while ("<(.*)>(.*)</\\1>" matches "some text here" ) {
    whatever processing we want to put here
    }
    or we can use variables:
    while (myPattern matches someInput )
    or method calls
    while (myPattern matches reader.getUserInput() )
    Macro definition would look like this

    - I think, this could be a nice way to develop what is called "Domain specific languages" - yet another alternative to OOP.
    to quotes from books which often seem to be taken out of context.
    Quotes always are taken out of context, by definition. In case of inheritance, I finally typed almost all section, because I considered it important. (and hopefully more people now will go and buy the book ). I was going to post the implications from "composition vs. hierarchy" yesterday, but was distracted with "real life". :roll: Here it is.
    It seems to me that Mr. Bloch basically said that composition is in all ways superior to inheritance, the only disadvantage is that it precludes callback functionality. This paper interesting in many other ways also seemingly solves SELF problem by introducing yet another level of indirectness. (for C++, but I suppose the same would work for Java):
    "The layer is implemented such that the self pseudo variable references the object encapsulated by the Bridge layer rather than the object that is redirected to, thereby avoiding the self problem."
    Does that mean we get rid of inheritance now? It would simplify the language greatly.
    Here I am going far out of competence, so hopefully somebody will correct me if I missed something.
    First, we get rid of class-object distinction, since the only purpose of "instantiating" a class as an objects was to call super-class' constructor to inherit all what should be inherited, we get rid of constructors. If we need to provide initialization, simple assignment will work. PL/1-like structures will do the job. Or are there other benefits of using constructors?
    Next, no more class/instance methods distinction + no more overriding. Overloading will stay here, since it's only syntactic sugar.
    Hierarchy of interfaces is here, because through interfaces we are getting polymorphical calls.
    There are mountains of problems we are freed ourselves from (default non-argument constructor and what will happen if superclass doesn't have one, constructors must not invoke overridable methods, etc etc etc.)
    I am going to walk through an example to see if this will work, for not to be too theoretical... Ilja, you do not have to respond, if you think it's too theoretical and you are not interested, maybe somebody else will.
    Hey, everybody is doing what they are good at. All other threads in this forum are "practical", so I figured I can start one "unpractical" - for the sake of diversity :roll:
    Why my posts are always so long, I have no idea...
    [ August 25, 2002: Message edited by: Mapraputa Is ]
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    Map, I don't see why you keep quoting Bloch to make a point -- he doesn't agree with you at all.
    The moral of his words: be careful and don't do anything stupid.
    Your response: OO is bad because Bloch says you can do stupid things, and some things can't be done.
    My response: Can't you do stupid things with relational databases too? Aren't there things that relational programming (whatever that is) can't do?
    Mapraputa Is
    Leverager of our synergies
    Sheriff

    Joined: Aug 26, 2000
    Posts: 10065
    Map, I don't see why you keep quoting Bloch to make a point -- he doesn't agree with you at all.
    This is an interesting theore... ah, sorry, interesting practical problem. Is "agreement" symmetric, i.e. does
    M a B => B a M
    Or its's Ok when M a B but B not a M?
    "Can't you do stupid things with relational databases too?" - of course, you can. If you violate the rules of the game. In case of OOP (I should probably say more careful "Java version" of OOP) it stroke me that you get problems even if you do not do anything disadvised. And some problems got discovered later, so creators of Java API think they are doing perfectly good things, yet later their classes exhibit "erratic behavior", as Bloch put it, or, in other words are incorrect.
    To my knowledge, nothing like this ever happened to relational model. Perhaps implementation of it can suffer from performance or some other problems, but its logic doesn't cause problems - if you followed a few simple rules, you get correct result. No erratic behavior, no "fragile classes", no discoveries about problems with equals method (read: entity identity) Of course, relational model is much simpler than OOP, and after reading "Effective Java" I believed that this is the case why OOP brings surprises - that OOP is too complex and unexamined area for our current state of knowledge. Then I read that C.Date and F.Pascal POV that this is because their model is based on solid scientific theory, and OOP is not. In other words, the fact that OOP is craft rather than science is not an inherent unevitable feature of OOP, but rather sad consequence of "ad hoc approach" chosen by its creators.
    I do not know how true the above POV is, since I am not a computer scientist. But I thought it is important to give their views some audience, since they seem to be marginalized by media.
    I did not imply that everybody should immediately quit using Java. I did want to attract your attention to their claim that relational model abilities are largerly misunderstood and underestimated (and this very thread only proves it). I worked with relational databases and had very satisfying experience, I've been missing SQL functionality ever since. Part of my rant against OOP stem from its apparent desire to do in a very complicated way what could be done with DB with far less efforts.
    "Can't you do stupid things with relational databases too?" - the whole site I am digging quotes from is dedicated to the sad condition relational databases industry is. (OOP is of tangential interest). They believe that the reason for this sad state is an abssence of fundamental knowledge in general IT public and concentrating on concerete vendor products. When I gave a quote you did not even believe I am serious! :roll: Well, Ok, if you do not believe two weird guys, then maybe you will listen to what your own guru is saying? That's why I switched to Joshua Bloch writings.
    Aren't there things that relational programming (whatever that is) can't do?
    All relational model is about is data management: queries and updates. It cannot parse an XML, for example. But if this part can be yield from an application, it can be a huge progress. There may be other problems, yet not as fundamental as with OOP, I believe.
    OOP is cool, I agree. But when I added a column into a table, it didn't break my old queries either. I believe "relational programming (whatever that is)" deserves some interest. In particular, they claim that their model supports user data types and inheritance as well. And that relational model (not how it is currently implemented, though) can support hierarchy better than hierarchical model itself. I am going to learn more after I am done with this rant Particularly, because I tend to trust people who can explain things in such a clear and strict manner, rather than define fundamental concepts as "something with responsibilities".
    [ August 25, 2002: Message edited by: Mapraputa Is ]
    David Weitzman
    Ranch Hand

    Joined: Jul 27, 2001
    Posts: 1365
    I wouldn't call Bloch so much an OO guru as a Java guru, but either way I agree completely that at first even the people that invented OO had trouble using it properly -- it's a craft as you say. Would you go so far as to claim that relational database programming is not a craft, and that someone with five years experience has no leg up over someone with five days experience?
    Mistakes were made in designing the java libraries because nobody realized that there was such a thing as bad OO. Now Bloch can explain why some of the earlier patterns were poor choices. And he does it along with thousands of others in a very public way. Let me reword:
    OO is a science, like biology or quantum physics. There was a time when a doctor was as likely to kill you as help you, or when people believed atoms were the smallest of particles. Despite some mistakes, scientists have reliably corrected themselves and improved my quality of life. Hey, that must be why they call it Computer Science!
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: OOP considered harmful (was: C. Date on UML book)
     
    Similar Threads
    UML component diagram
    Best IBM cert ?
    UML Certification
    WA #1.....word association
    defualt multiplicity is 1 or 1..many?