You are missing a clear

understanding of the computational model underlying almost all OO

programming languages, and that computational model is as linear
as a Turing



Could you elaborate please?


--
Posted via http://dbforums.com

Originally posted by Bob Badour

I was refering to "...better to persist your objects as objects
(rather than creating tuples from them..." , not to your response to
that per se.



That to me suggested (advising against) breaking an object down into
several tuples. And the old car analogy cliche sprang to mind...


--
Posted via http://dbforums.com

"Bob Badour" <bbadour (AT) golden (DOT) net> escribió en el mensaje
news:UgG8b.242$yZ2.13422648 (AT) mantis (DOT) golden.net...
All objects belong to a class. All classes form a hierarchy so that:

1. Most methods are "reused" from the top.
2. No class has spurious methods.
3. The class hierarchy is deep.
4. Most classes have few methods (no more than 10).
5. Most methods are small (no more than 10 lines).
6. Classes are simple and easy to use. Each class represents a single
concept and it is almost impossible to use it in a wrong way.
7. When new functionality must be added, most of the functionality can be
added using the "template method" pattern.
8. Most of the code follows the DRY principle.

Cheers,
Guillermo.

Excellent summary.
Thanks,
--
Bob Nemec
Northwater Objects

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

Trivially true (even for C++ and Java not that they have anything to
do with data management.)


I respectfully suggest that classes or types naturally form a DAG and
not a hierarchy. (Not that C++ or Java do any better with that than
Smalltalk, but I do think it demarks a clear cognitive bias among
Smalltalk practitioners who do not use an extended version of the
language supporting multiple inheritance.)


Most but not all? Seems arbitrary and thoroughly subjective. Should I
note that (even in C++ and Java) reuse always happens from above?


How is this property affected by the chosen language? What makes a
method spurious? How does a spurious method detract from the 'full
sense', which you have yet to describe? (A hodge-podge of arbitrary
rules for achieving a sense does not describe what the sense is.)


I've seen some pretty deep hierarchies in C++ and in Java. How does
one know when one has reached the required depth of hierarchy? Can the
hierarchy ever be too deep? How does one know? After all, naively
maximizing depth will only maximize complexity. Does the 'full sense
of OO' equate to 'maximal complexity'?


There goes that 'most' again. Why not all classes? Again, the
statement is meaningless due to its arbitrariness and subjectiveness.
Why 10 methods? Can smalltalk programmers only count using their
digits? What if my amp goes to 11? Does this mean that a mathematics
system with a class with methods for addition, subtraction,
multiplication, division, exponentiation, logarithm, sine, cosine,
tangent, secant, arcsine, arccosine, arctangent and arcsecant fails to
achieve OO-ness in its full sense? That wouldn't make OO-ness in its
full sense particularly attractive to me.


Most methods? Not all methods? How do we know when we have achieved
most-ness? Why 10 lines? Is this the finger thing again? If a
smalltalk programmer loses a pinkie in a tragic filing accident, does
he have to limit his methods to 9 lines?


VCR is a single concept, and mine is flashing 12:00am at me as I write
this. Come to think of it, I only use this VCR to elevate my monitor;
although, at one time, I used it as a television tuner by hooking it
to an old Commodore-64 monitor. Infinity is a single concept too.
Heck, logic is a single concept and I find it quite easy to use, but
lots of folks seem to disagree with me. Does this mean we can only
achieve OO-ness in its full sense by ignoring complex or difficult
things?


Trivially true for any language supporting polymorphism (including C++
and Java not that they have anything to do with data management per
se.)


Most but not all...? From a data management perspective, the DRY
principle argues strongly for logical and physical independence as
well as logical identity.

"Bob Badour" <bbadour (AT) golden (DOT) net> escribió en el mensaje
news:cd3b3cf.0310061723.584e0d59 (AT) posting (DOT) google.com...
It is important because an object cannot change classes dynamically. At
least not yet ;-)
DAG == Direct Acyclic Graph?

C++ has multiple inheritance, so it has multiple path to get from one node
to the other, yet none of them have cycles when speaking of hierarchy, but
they do have cycles when instance variables and functinality is taken into
consideration.

Usually you create applications by adding classes at the bottom
(subclasses), rather than by adding classes at the top (superclasses), so it
is the subclasses that generally reuse the code from the top.

If I'm missing something, please correct me.
It has nothing to do with the language but with the class hierarchy (or
should I rather say the class library?)

An spurious method is one that does not belong to the class, but was added
to the wrong class because refactoring the class library would be too
burdensome for the project at hand.

Sometimes you realize the methods are spurious long after the method was
written. I think XPers call that feature envy or something like that. I
might be wrong thought.

A non-spurious method is one that actully belong to the class.

You are right. This is a case of IKWISI (I'll Know It When I See It). To
make matters easier to understand, you create a class for one purpose and
only one purpose. Then you realize that in that purpose, there are really
two orthogonal purposes and the class must be divided in two. Then the
methods that belong to the *new* class are spurious, untill you remove them.
I've never keep statistics of this, and I know I should have. IMHO it has to
do with the average number of direct subclasses. It should be a number
between 1 and 6, or maybe between 1 and 3. If the average is 20, probably
you are not reusing much.

I wonder the same. I've never done experiments about this, but I imagine
that it is possible to conceive a sublanguage of Smalltalk that would allow
to define only 1 method per class. Then all classes could be translated into
this new scheme. The purpose, try to reuse most of the methods. There are
some rough edges like what to do with instance variables, since you would
have to write either a setter or getter, it would be impossible to write
both.

So yes, it can be too deep if you don't write all required setters and
getters in the appropiate class. That of course never happens in real life,
so the answer IMHO is that it can never be too deep.

Actually I've never seen anything simpler than reading a hierarchical class
library. You just need to learn the classes at the top and the rest you can
learn when you actually need to. It is simple to find new classes.

How come?

Imagine compressing the class library into 10 classes. Then it would be very
hard to use. Where did you store the state of the XYZ object? Yes, in a X1
class, because that's all you have. Of course tht would mean you would never
create objects (they are too big) but reuse them, so most programs would be
a mess.

Also forget about subclassing those fat classes.

Maybe it does for you. For me, OO means deep hierarchies => each conceptual
object is represented by an object in the target languge, finding class is
easy because the hierarchy is deep, subclassing is easy because classes are
not too fat.
Because programmers are lazy. ;-)

Let us suppose you are about to finish the system, you have 1 hour and you
need to add this 3 methods to the D class in the following hierarchy:

A -> B -> C -> D, so that D inherits from C and so on.

The four classes already has 10 methods.

Then you can create E, but most of the code alredy instantiates D, so you
would need at least 2 days to do that change.

What else can you do? Add a class E between C and D, so that C -> E -> D,
and add those 3 method there. But what if you need to access the instance
variables in D? You need to move the instance variables from D to E, but you
cn't move them all, or you will have to move all methods, so E will have the
same problem.

Meaningless? Maybe arbitrary (which is the same as subjective), but I can
measure how many methods class has, so I have an objective and a way to
measure if I have achieved it, I don't see how it is meaningless.

Why not?

You need to establish limits. Yes they are arbitrary, as limits among
countries.

HA HA

Only those methods? If you are creating a math system, probably you will
add a hundred methods like that. Also you will add the sqrt method, you can
do it at the Integer class and at the Float class. Then you write isqrt
which returns the integer part of sqrt, and of course you reuse sqrt, so you
write:

Number>>isqrt
^self isqrt asInteger.

Then what would?

Well, maybe the if the Nazis had invented Smalltalk they would hve added
that requirement at the VM level, so that no Smalltalk program would have
run if they didn't comply. These are guidelines, not strict requirements,
relax.

That's a good question. What about "not more that 10% of the system does not
comply and the average is not exceeded by more than 10%".

Maybe I like the number 10?

Maybe.

What is pinkie?
What is filing accident?
There is a problem between the VCR and the chair.

If the VCR is so simple, why doesn't it have a hard drive instead of the VHS
tape drive? Why doesn't it connect to the internet to synchronize the time?
Why doesn't it learn what I like to see and store my favorite programs?

You think the VCR is simple, but actually it is cumbersome and almost
useless.

I see why.

That's interesting.

I don't think OO is simple. You can get a PhD in OO. If you think OO is a
sham, it is probably because you haven't looked at it carefully.
You understand patterns but you don't understand OO. Then you must be
manager.
That statement is too abstract to be argued against. You can say the same
thing about anything, for example:

OOP "argues strongly for logical and physical independence as well as
logical identity".

Actually the DRY principle is the guiding rule for all the "most"s and "10"s
above.

"Guillermo Schwarz" <guillermo_schwarz (AT) hotmail (DOT) com> wrote

I realise that english is probably not your first language. Do you
comprehend what "trivial" means?

You still have not explained what the "full sense" of OO is.


Yes.


As I said, neither C++ nor Java do much better than Smalltalk. Types or
classes, however, properly form a DAG.


Do you have a point that wasn't already clearly a part of what I wrote
above?


Do you comprehend "arbitrary" and "subjective" ?


In other words, this problem is not unique to Smalltalk.


You have not provided an answer; you have simply added an extra level of
misdirection. What makes a method belong to a class?


In other words, whether a method is spurious or essential is entirely
arbitrary and subjective.


Your statement does not answer the question; it simply repeats the extra
level of misdirection above.



I have seen plenty of C++ and Java code that matches the rather meandering
description above. I guess then you agree that C++ and Java code is OO in
the full sense.


It seems to me that with 20 subclasses you are reusing the superclass a lot
more than with 3 or 6 subclasses. Do you even know what you are saying? This
contradicts what you wrote previously on the same point.


[longwinded rambling "yes" snipped]


How not? Maximizing depth increases the number of types and the number of
edges in the inheritance DAG.


How does a deep DAG make finding anything easy? Please explain with a
concrete example.


[longwinded rambling non-answer snipped]


Perhaps, when you realise the difference in meanings between "arbitrary" and
"subjective", you will have a better grasp of "meaning" itself.


Indeed. Why not 9 methods or 11 methods? In computing, we generally only
recognize three numbers: 0, 1 and some arbitrarily large power of 2. Why 10?


Why? If a type has 12 essential methods, how would it fail to achieve the
nirvana of "full sense OO-ness" ?


Why? What else is necessary?


The class or type already has exponentiation. Why wouldn't the design lose
its "full sense OO-ness" by adding a non-essential method even after it has
already exceeded the arbitrary limit you imposed?


Utility. Aesthetics.


A guide is only as valuable as the destination to which it directs one. I
still have yet to meet a smalltalk programmer who can articulate anything
useful regarding the so-called "full sense" they stupidly and arrogantly
disparage other programmers for failing to achieve.


I cannot parse anything meaningful out of that, and I have above average
skills at parsing the english language.


I guess the humour lost something in translation.

A pinkie is generally the shortest finger of the hand and the farthest
finger from the thumb (assuming five or more fingers per hand.)


An accident that occurs while filing something.


Because then I would not be able to play the movies I rent at blockbuster.
You are getting confused with the TIVO class.


Because then it would tie up my fax line all the time.


Because it is my VCR and not yours. It often stores my current favourite
movie.


Bite your tongue! I use my VCR all the time. It's one of the most useful
toys I own, and I own a lot of toys.


What the hell gives you the idea I think OO is a sham?

Look, one can have a well-informed opinion regarding OO fully recognizing
the strengths and limitations, and one can still think smalltalk programmers
are a bunch of arrogant, dilettantish posers.


I have been writing OO'd software professionally since 1988 with tremendous
success. What makes you think I lack any understanding of OO? You clearly
lack a clue.


The statement is too correct to be argued against. If you comprehend the DRY
principle, you will obviously agree that it argues strongly for data
independence as well as logical identity.


Except that OOP does not. OOP generally specifies a computational model
relying on a linear address space where the physical location in the address
space determines identity (often spuriously.)

DRY argues neither for nor against OOP, per se, but it argues very strongly
for data independence and logical identity for data management.


I find your last statement simply non sequitur.