Business applications of Object Technology
billg
with Object Technology?
+billg
oblomov
Maybe.
Please define usefullness and unique problem domains of business world.
karl
Topmind
H. S. Lahman
> Can the unique problem domains of the business world be usefully modeled
> with Object Technology?
That depends on what you mean by 'unique' and the purpose of the models.
If you are referring to Business or Domain modeling, notations like
UML can be used but they usually require some bending.
If you are referring to using OT to model software solutions in problem
domains, then the short answer is Yes. In fact, it is important for
large OO application models to recognize unique problems domains. But
one is not directly modeling the problem domain in doing so. One is
abstracting from it the essentials for the solution in hand. Also, OT
is not suitable for all possible unique problem domains.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Uncle Bob (Robert C. Martin)
about) Sat, 11 Jan 2003 19:59:22 -0500, :
>Can the unique problem domains of the business world be usefully modeled
>with Object Technology?
Object technology is a software implementation and design technology
that is universally applicable to all kinds of software. For the most
part, OO is a technique for structuring source code so as to reduce
coupling.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
"...a member of my local hiking club is a
nudist. I once asked him if he ever hiked in the nude. He responded
that he was a nudist, he wasn't nuts."
-- Daniel Parker
billg
> that is universally applicable to all kinds of software. For the most
> part, OO is a technique for structuring source code so as to reduce
> coupling.
I don't see how OT reduces coupling. My impression was that it is a
methodology ideally suited to modeling concrete entities. For example, a
car, a clock, a dog, or a graphical user interface. What about modeling
abstract entities? Does this present a problem in any particular areas of
application?
+billg
Phlip
>> Object technology is a software implementation and design technology
>> that is universally applicable to all kinds of software. For the most
>> part, OO is a technique for structuring source code so as to reduce
>> coupling.
>
> I don't see how OT reduces coupling.
"Coupling" means "A has to change for no reason other than B changed". In a
"structural programming paradigm", if you wrote B first, then A, then you
split B into B and C, A would now need an "if" statement or something to
select one of B and C.
In an OO paradigm, A may be unaware that the B passed to it is really a C.
This lets old code call new code. A calls B's methods using "virtual
dispatch", so the decision between B and C happens at runtime.
> My impression was that it is a
> methodology ideally suited to modeling concrete entities. For example, a
> car, a clock, a dog, or a graphical user interface.
That's "object based", meaning data and functions come together in little
packets. You can do that in C language by passing a pointer to a structure
into each of a set of functions.
> What about modeling
> abstract entities?
> Does this present a problem in any particular areas of
> application?
Why should it? "OO" doesn't mean you >must< use virtual dispatch. You use
it to solve a problem. If you don't have that problem, don't use it.
Now read the book /Refactoring/ and the item "Replace Conditional with
Polymorphism".
--
Phlip
http://www.greencheese.org/DontPlanDesigns
-- "Why have an attention span when you can
have a staff [of lawyers]?" -- Ian Sholes --
Phlip
>> abstract entities?
Some of your classes will have pure virtual or otherwise unresolved
methods. Those classes should only be inherited.
Some classes are ready to run without further adjustments; they are
concrete.
Read /Design Patterns/.
If you think this has anything to do with the Real World, where some things
are abstract and concrete too, it isn't. It's a pragmatic way to simplify
your program's internal structure.
--
Phlip
http://www.greencheese.org/SkeletonCrew
-- My opinions are those of your employer --
Topmind
> about) Sat, 11 Jan 2003 19:59:22 -0500, :
>
> >Can the unique problem domains of the business world be usefully modeled
> >with Object Technology?
>
> Object technology is a software implementation and design technology
> that is universally applicable to all kinds of software. For the most
> part, OO is a technique for structuring source code so as to reduce
> coupling.
Coupling is not something to always
reduce. Coupling is something to *manage*. For
coupling has GOOD sides too. For one, it allows you
to keep things in a group or package such that you don't have
to manage each little element by itself. IOW, coat-tails.
Classes and modules and routines and inheritence and
"types" and schemas are all concepts that "package"
things togther. IOW, coupling.
A breif-case couples a bunch of stuff together so that
we don't have to carry each item by itself. If we need
our cellphone often, then we perhaps want to decouple
it from the breif-case (take it out) for a while, for
instance.
In a nut-shell, coupling is good when it fits requirement
change patterns and bad when it does not.
Besides, coupling is kind of a vague term which
comes in all kinds of shapes and sizes, some of
them not readily appearent. Polymorphism has
coupling in it too. OO philosophy is *not* couple-free.
(Seasoned comp.ob'ers know this story already so I
won't repeat it.)
It all comes down the estimating future change
patterns and finding the balance of coupling to
best fit it. That is the key fish in these debates,
not coupling itself.
>
>
> Robert C. Martin | "Uncle Bob"
-T-
Topmind
>
> >> Object technology is a software implementation and design technology
> >> that is universally applicable to all kinds of software. For the most
> >> part, OO is a technique for structuring source code so as to reduce
> >> coupling.
> >
> > I don't see how OT reduces coupling.
>
> "Coupling" means "A has to change for no reason other than B changed". In a
> "structural programming paradigm", if you wrote B first, then A, then you
> split B into B and C, A would now need an "if" statement or something to
> select one of B and C.
>
> In an OO paradigm, A may be unaware that the B passed to it is really a C.
> This lets old code call new code. A calls B's methods using "virtual
> dispatch", so the decision between B and C happens at runtime.
Dynamic dispatch was not something born with OO. LISP was known for
it in the 50's, I would note. OO cannot take credit for dynamic
dispatch unless LISP invented OO. (And LISP probably was not first
either.)
C is NOT the pennical of "structured programming". I really
hate it when object books use C to bash the whole of "structured
programming".
-T-
S Perryman
news:3e223c31$2...@news.myusenet.com...
> > Object technology is a software implementation and design technology
> > that is universally applicable to all kinds of software. For the most
> > part, OO is a technique for structuring source code so as to reduce
> > coupling.
> I don't see how OT reduces coupling.
OO (mainly thru ADTs) offers a few new slants on addressing old s/w
coupling issues. Issues that are known and already solved by the structured
paradigm.
It also offers some new coupling techniques that are not available to the
structured paradigm.
Regards,
Steven Perryman
H. S. Lahman
It is very much about decoupling, particularly dependencies between
implementations. At the OOA/D level that is accomplished via
encapsulation. Essentially OO encapsulation is a formalization of good
modularization at a much finer scale than traditional modules whose
implementation was hidden behind APIs. At the OOP level it is more
directly done through dependency management techniques, where an
important tool is polymorphism to allow more generic access.
Actually one of the main advantages of OT is its the ability to
routinely model abstract entities. That allows things like a Dog
License to represent much more than a piece of paper. It also allows
one to deal with completely abstract concepts like Arbitration.
Uncle Bob (Robert C. Martin)
>> Object technology is a software implementation and design technology
>> that is universally applicable to all kinds of software. For the most
>> part, OO is a technique for structuring source code so as to reduce
>> coupling.
>
>I don't see how OT reduces coupling.
Imagine you have a system that uses modems to talk to other systems.
Imagine also that there are many different kinds of modems, each with
its own particular API and protocol for operation. Even though the
details for operating the modems are wildly different, the kinds of
things you can do with the modems are all about the same. For
example, you can dial a remote computer, you can send bytes through
the modem, you can receive bytes from the modem, and you can hang-up
the modem.
Prior to OO technology we might have implemented this as follows:
void dial(Modem m, String phoneNumber) {
switch(m.type) {
case COURRIER: dialCourrier(m, phoneNumber); break;
case USROBOTICS: dialUSR(m, phoneNumber); break;
case HAYES: dialHayes(m, phoneNumber); break;
}
}
Or worse, the switch statement might have been repeated at every
position in the code where we wanted to dial. Worse still, the switch
statement is repeated for send, receive, hangup, and every other
operation we want to perform on the modems.
These switch statement are very tightly coupled to all the details of
all the different modems. If you manage the dependencies leaving the
switch statement, those dependencies point to every possible modem
type. Worse, every module in the system that does anything with modems
depends upon the switch statements. Therefore every module in the
system that does anything with modems depends transitively upon every
different kind of modem. The coupling problems are enormous and lead
to code that is very difficult to maintain and very easy to break.
OO technology breaks this coupling by using indirection. The object
oriented designer creates an interface that describes all the possible
operations of a modem:
public interface Modem {
public void dial(String phoneNumber);
public void send(byte b);
public byte read();
public void hangUp();
};
This interface define what you can do to a Modem, but does not know
anything about the different kinds of modems. The modules that use
modems can now describe what they want to do in terms of this
interface.
Modem m = /* get the modem from somewhere */;
m.dial(pno);
In the above m refers to some objects that implements the Modem
interface. the m.dial(pno) expression has a particular meaning in OO.
It means that we are sending the 'dial' message to the object referred
to by 'm'. Thus, the modem object referred to by 'm' can deal with
the 'dial' message as it deems fit. This means that the module that
invokes m.dial does not depend, in any way, upon the modules that
implement the dial function.
For example, the HAYES modem might be implemented like this:
class HayesModem implements Modem {
public void dial(String phoneNumber) {...}
public void send(byte b) {...}
public byte read() {...}
public void hangUp() {...}
}
The users of the Modem interface have no direct or transitive
dependency upon HayesModem. The binding between the call to 'dial'
and the actual invocation of HayesModem's dial function is
accomplished at runtime. In effect, m.dial causes 'dial' to be looked
up in a table contained within 'm'. That table holds a pointer to the
function that should be called. Thus, the coupling of the caller to
the callee occurs at runtime, not at compile time.
This means that the callers can be deployed independently of the
callees. The users of Modem can be placed in one DLL, for example,
and each modem implementation can be placed in its own DLL. We can
deploy only those modem implementations that we need.
This ability to use runtime binding to manage dependencies is very
powerful. It allows us to completely isolate the modules that contain
high level policy from those that contain low level implementation
details. Indeed, there are many such levels in any system, and using
OO we can isolate them all from each other.
>My impression was that it is a
>methodology ideally suited to modeling concrete entities.
The notion that OO is about modeling is a relatively late idea. OO
was invented in the late 60s by programmers who were studying program
structure. They found that objects created superior software
structures, but also noted that they increased the expressivity of the
software. Over time this increase of source code expressivity has
been erroneously translated into a concept about building models
separate from source code.
>For example, a
>car, a clock, a dog, or a graphical user interface.
In OO every object has a suite of functions that it can perform.
Those functions are specific to the application being built. It is
meaningless to talk about a 'car', 'dog', or 'clock' object without
knowing what the application is. For example, if the application is
management of a kennel, then there might well be 'dog' objects. The
functions within those 'dog' objects might be database operations that
allow you to ask when a dog has last been fed, watered, or walked.
They might check the dog into the kennel, or check it out. Those
functions would be very specific to management of the kennel as
opposed to general functions about dogs.
>What about modeling
>abstract entities? Does this present a problem in any particular areas of
>application?
No. If a concept, regardless of how abstract it might be, can be
described as a set of variables and functions, then you can create an
object out of it.
Alfredo Novoa
> Can the unique problem domains of the business world be usefully modeled
> with Object Technology?
Problems domains of the business world are better modeled with
relational designs.
Object technology is usually intended to solve imperative coding
issues, but using RDMBSs we don't need to code for solving the most
part of the business world domain problems.
Alfredo
Phlip
> > > I don't see how OT reduces coupling.
> >
> > "Coupling" means "A has to change for no reason other than B changed". In a
> > "structural programming paradigm", if you wrote B first, then A, then you
> > split B into B and C, A would now need an "if" statement or something to
> > select one of B and C.
> >
> > In an OO paradigm, A may be unaware that the B passed to it is really a C.
> > This lets old code call new code. A calls B's methods using "virtual
> > dispatch", so the decision between B and C happens at runtime.
>
> Dynamic dispatch was not something born with OO. LISP was known for
> it in the 50's, I would note. OO cannot take credit for dynamic
> dispatch unless LISP invented OO. (And LISP probably was not first
> either.)
Nobody said OO invented dynamic dispatch. Just that DD is how OO
decouples.
> C is NOT the pennical of "structured programming". I really
> hate it when object books use C to bash the whole of "structured
> programming".
So if you were to answer the question "how does Object Technology
reduce coupling", and if you defined coupling, and if you recognized
the question is >not< "Is OT the best way to reduce coupling", then
how would you answer?
Per your complaints, your answer would be very similar to mine, but
with different examples.
--
Phlip
http://www.greencheese.org/LucidScheming
-- I'l have my Web site call your Web site... --
Topmind
> about) Sun, 12 Jan 2003 23:26:00 -0500, :
>
> >> Object technology is a software implementation and design technology
> >> that is universally applicable to all kinds of software. For the most
> >> part, OO is a technique for structuring source code so as to reduce
> >> coupling.
> >
> >I don't see how OT reduces coupling.
>
> Imagine you have a system that uses modems to talk to other systems.
> Imagine also that there are many different kinds of modems, each with
> its own particular API and protocol for operation. Even though the
> details for operating the modems are wildly different, the kinds of
> things you can do with the modems are all about the same. For
> example, you can dial a remote computer, you can send bytes through
> the modem, you can receive bytes from the modem, and you can hang-up
For a counter-view of this, please see:
http://geocities.com/tablizer/prpats.htm#dispatch
(I am kind of tired of device driver examples, BTW.
Most developers don't write device drivers and the
regularity/repetition of device interfaces is often
not found in the biz domain. I want to see how
OO handles masses of interlinking orthogonal
aspects in biz apps. That would be a better show.)
-T-
Topmind
But it is almost like saying that "OO reduces X because it
has variables". That is not very useful information IMO
unless variables were rare except under OOP.
Technically you are correct perhaps. But it does not
paint an accurate picture about what is unique
or special about OO.
>
> --
> Phlip
> http://www.greencheese.org/LucidScheming
> -- I'l have my Web site call your Web site... --
>
-T-
Mikito Harakiri
message news:9jo52vg5paitafp61...@4ax.com...
> OO technology breaks this coupling by using indirection. The object
> oriented designer creates an interface that describes all the possible
> operations of a modem:
> switch(m.type) {
> case COURRIER: dialCourrier(m, phoneNumber); break;
> case USROBOTICS: dialUSR(m, phoneNumber); break;
> case HAYES: dialHayes(m, phoneNumber); break;
> }
> }
>
> public void dial(String phoneNumber);
> public void send(byte b);
> public byte read();
> public void hangUp();
> };
>
Modem object, so that a switch like you describe never appared in any driver
code. Second, would you be able to abstract your class to embrace cable
modems as well?
Networking layer abstraction serves the same protocol decoupling purpose
that objects do. It's language and object unconscious, but, nevertheless,
wildly successfull. Higher level object protocols (Corba, COM, RMI, Soap)
are struggling to get that degree of acceptance yet.
Phlip
> > "billg" <bi...@aol.net> might (or might not) have written this on (or
> > about) Sat, 11 Jan 2003 19:59:22 -0500, :
> >
> > >Can the unique problem domains of the business world be usefully modeled
> > >with Object Technology?
> >
> > Object technology is a software implementation and design technology
> > that is universally applicable to all kinds of software. For the most
> > part, OO is a technique for structuring source code so as to reduce
> > coupling.
>
>
> Coupling is not something to always
> reduce. Coupling is something to *manage*. For
> coupling has GOOD sides too.
Right. Part of the definition of "coupling" is that it is bad (unlike
real life coupling). The good kind is "cohering".
> For one, it allows you
> to keep things in a group or package such that you don't have
> to manage each little element by itself. IOW, coat-tails.
> Classes and modules and routines and inheritence and
> "types" and schemas are all concepts that "package"
> things togther. IOW, coupling.
>
> A breif-case couples a bunch of stuff together so that
> we don't have to carry each item by itself. If we need
> our cellphone often, then we perhaps want to decouple
> it from the breif-case (take it out) for a while, for
> instance.
>
> In a nut-shell, coupling is good when it fits requirement
> change patterns and bad when it does not.
>
> Besides, coupling is kind of a vague term which
> comes in all kinds of shapes and sizes, some of
> them not readily appearent. Polymorphism has
> coupling in it too. OO philosophy is *not* couple-free.
> (Seasoned comp.ob'ers know this story already so I
> won't repeat it.)
>
> It all comes down the estimating future change
> patterns and finding the balance of coupling to
> best fit it. That is the key fish in these debates,
> not coupling itself.
Right. And the best way to estimate future change patterns is to let
historic change patterns influence your codes partitioning and
abstraction.
--
Phlip
http://www.greencheese.org/AndNowaNitelyLitelyUrbanOne
-- Whoever dies with the most features wins --
Phlip
> > This lets old code call new code. A calls B's methods using "virtual
> > dispatch", so the decision between B and C happens at runtime.
>
A> Pinnacle
B> C is the name of an arbitrary class, as are A and B.
> I really
> hate it when object books use C to bash the whole of "structured
> programming".
It's the one students are most likely to have heard of (especially
those who read the entire text).
--
Phlip
http://www.c2.com/cgi/wiki?CowBoy
-- Friends don't let friends use Closed Source software --
Uncle Bob (Robert C. Martin)
written this on (or about) Mon, 13 Jan 2003 10:58:36 -0800, :
>"Uncle Bob (Robert C. Martin)" <u.n.c.l...@objectmentor.com> wrote in
>message news:9jo52vg5paitafp61...@4ax.com...
>> OO technology breaks this coupling by using indirection. The object
>> oriented designer creates an interface that describes all the possible
>> operations of a modem:
>> void dial(Modem m, String phoneNumber) {
>> switch(m.type) {
>> case COURRIER: dialCourrier(m, phoneNumber); break;
>> case USROBOTICS: dialUSR(m, phoneNumber); break;
>> case HAYES: dialHayes(m, phoneNumber); break;
>> }
>> }
>>
>> public interface Modem {
>> public void dial(String phoneNumber);
>> public void send(byte b);
>> public byte read();
>> public void hangUp();
>> };
>>
>I think this example is misleading. First, the modem protocol never needed a
>Modem object, so that a switch like you describe never appared in any driver
>code.
Actually this example comes from a real example. Thirty years ago I
worked on a system that had many modems, all exactly alike. The
modems were represented by a data structure that contained their IO
addresses, counts, and flags. In order to contact a remote system you
would get a free modem from the pool of modem data structures, and
then you'd dial the modem. Dialing was a matter of looping through
the digits and passing them into the modem. This was done in dozens
of places in the code. There was no standard dialling function. This
was because 1. The dialing code was simple and 2. the system was
written in assembler and the overhead for making a function call was
high.
At some point a new modem card was introduced. The details of this
card were completely different from the first, but it would plug into
the same hardware slots as the old card. Our systems had to be able
to work with a mix of old and new cards installed.
Thus, we had to find every place in the code that used the old modem
and put the appropriate 'if' statements in. We thought about putting
the dialing code into a subroutine then, but we found it was
impractical because every place in the code that dialed, did it in a
slightly different way and expected slightly different flags and bits
to be set. It turned out that the simplest change was to put all the
'if' statements (actually SZA instructions) in.
Later, that system was rewritten in C++; and the Modems were
restructured as I described above.
>Second, would you be able to abstract your class to embrace cable
>modems as well?
That's actually an exercise I give my advanced OO students. The
problem is non-trivial. The Dial and Hangup functions no longer apply
for a Cable modem, and yet we still want to be able to send and
receive bytes. We also want the programs that use the Modem interface
to be able to use Cable Modems.
You can see this particular problem written up, complete with
solutions, on page 320 of "Agile Software Development: Principles,
Patterns, and Practices", Robert C. Martin, Prentice Hall, 2003.
www.objectmentor.com/PPP
>Networking layer abstraction serves the same protocol decoupling purpose
>that objects do.
Indeed, they are nicely implemented in OO languages.
>It's language and object unconscious, but, nevertheless,
>wildly successfull.
Yes. Device independence is also a common decoupling technique that
does not require OO. Indeed, all the decoupling benefits you can get
from OO you can also get with simple tables of pointers to functions.
But OOPLS make it a lot easier to manage.
Our first languages had GOTOs and unstructured loops and ifs that
allowed undisciplined direct transfer of control. Structured
Programming came along and imposed discipline on direct transfer of
control. These disciplines are now expressed in our languages such
that GOTO is rarely present in a language, and rarely used if it is;
and the structured loops and ifs are used almost ubiquitously.
Our first languages had computed GOTOS, function pointers, or Alter
statements that allowed undisciplined indirect transfer of control.
OO came along and imposed discipline on indirect transfer of control.
Those disciplines are now expressed as abstract methods in classes of
OO programming languages.
>Higher level object protocols (Corba, COM, RMI, Soap)
>are struggling to get that degree of acceptance yet.
My own view is that those are solutions looking for problems. I don't
use them very often. If I want to communicate between two processes
I'll open up a socket.
Uncle Bob (Robert C. Martin)
on (or about) 13 Jan 2003 09:31:21 -0800, :
>"billg" <bi...@aol.net> wrote in message news:<3e20ba48$1...@news.myusenet.com>...
>> Can the unique problem domains of the business world be usefully modeled
>> with Object Technology?
>
>Problems domains of the business world are better modeled with
>relational designs.
Indeed, most object oriented models *are* relational models. However,
purely relational models lack any concept of behavior. What OO adds
to relational models is exactly that -- behavior.
However, it's important that we separate a few issues. Even in an OO
application we'll still use regular relational modeling for the
database. That's because we don't consider the database to be a bunch
of objects that contain behavior. Rather, we consider the database to
be a bunch of data that our applications use to create objects within
themselves and for their own purposes.
When we design our applications we partition their modules based upon
their behavior. We create object models that separate one kind of
behavior from another.
Tsolak Petrosian
I think the coupling/decoupling of code so that it can be used
somewhere else is totally wrong assumption. What we have to do instead
is finding the right responsibility of the component that couples that
code along in itself as module, class or package.
We already had a discussion about code (not component) reuse and I
still see the same preaching of writing half backed classes just for
the sake of coupling and code reuse.
Tsolak Petrosian
Uncle Bob (Robert C. Martin)
this on (or about) Mon, 13 Jan 2003 07:51:01 GMT, :
>Coupling is not something to always
>reduce. Coupling is something to *manage*.
Quite so. A completely decoupled program couldn't *do* anything.
Coupling is required in order to get anything done. On the other
hand, too much coupling makes it hard to make changes to the software.
>For
>coupling has GOOD sides too. For one, it allows you
>to keep things in a group or package such that you don't have
>to manage each little element by itself. IOW, coat-tails.
>Classes and modules and routines and inheritence and
>"types" and schemas are all concepts that "package"
>things togther. IOW, coupling.
Right. When we couple things that *ought* to be coupled, we call that
cohesion.
>In a nut-shell, coupling is good when it fits requirement
>change patterns and bad when it does not.
Yes.
>It all comes down the estimating future change
>patterns and finding the balance of coupling to
>best fit it. That is the key fish in these debates,
>not coupling itself.
Quite so.
All of which goes to the point that coupling needs to be managed, and
OO provides good tools to help manage coupling.
Robert C. Martin | "Uncle Bob"
JXStern
wrote:
>Coupling is not something to always
>reduce. Coupling is something to *manage*. For
>coupling has GOOD sides too.
I think it's also a new reality show from Fox.
Twenty bachelors, twenty bachlorettes, and one bed.
Don't fail to miss it!
J.
Universe
> Object technology is a software implementation and design technology
> that is universally applicable to all kinds of software. For the most
> part, OO is a technique for structuring source code so as to reduce
> coupling.
Ahhh, excuse us genuine all-around OO'ers (vs. "pragmatist Craftites"),
but per OO's creators - Dahl and Nygaard - it was intended to *reduce
complexity* thusly:
"Object-oriented [OO] programming. A program execution is regarded as
a physical model, simulating the behavior of either a real or
imaginary part of the world...The notion of a physical model should be
taken literally." ~ Computerized physical models
Madsen, Moeller-Pederson, Nygaard (co-founder of OO)
Elliott
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2003 my comments ~ newsgroups+bitnet OK
Topmind
> >In a nut-shell, coupling is good when it fits requirement
> >change patterns and bad when it does not.
>
> Yes.
>
> >It all comes down the estimating future change
> >patterns and finding the balance of coupling to
> >best fit it. That is the key fish in these debates,
> >not coupling itself.
>
> Quite so.
>
> All of which goes to the point that coupling needs to be managed, and
> OO provides good tools to help manage coupling.
grumble grumble
-T-
Richard Riehle
> I don't see how OT reduces coupling. My impression was that it is a
> methodology ideally suited to modeling concrete entities. For example, a
> car, a clock, a dog, or a graphical user interface. What about modeling
> abstract entities? Does this present a problem in any particular areas of
> application?
No. You might look at my example of an accounting class in another
thread. I will reproduce part of it here.
First some background, conventional accounting uses a formula,
Assets = Liabilities + (Owner's) Equity.
Assets, Liabilities, and Equity are kinds of Accounting entities
one could classify as belonging to an accounting class. The
operations most closely associated with an accounting class
are debit and credit. It is quite simple to model an abstract
accounting class that demands overriding of the debit and
credit operations.
In conventional accounting, if we wish to declare such a class,
we must understand that the a debit behaves differently depending
on the kind of account. So too, a credit behaves differently
depending on the kind of account.
An admittedly incomplete example follows:
abstract class Account is
debit_to (...); -- abstract methods
credit_to (...); -- abstract methods
-- additional methods, some possibly not abstract follow
private
-- structure of debits and credits
-- possibly replicating a T-Account model
end Account;
class Asset : derived from Account
debit_to ( ... ); -- this will increase the value of an asset
credit_to ( ... ); -- this will decrease the value of an asset
-- additional methods
private
-- possible addition attributes
end Asset;
class Liability : derived from Account
debit_to ( ... ); -- this will decreast the value of a
liability
credit_to ( ... ); -- this will increase the value of a
liability
-- additional methods
private
-- possible addition attributes
end Asset;
We can carry this further to represent Equity, Revenue, and Expense class
definitions. These, in turn can be associated with Entry Journals, Trial
Balances, and General Ledgers, all the while preserving their internal
behavioral and structural integrity.
In the other thread, where I posted this example, some people chose
to argue about its validity. I am not interested in arguing with those
people, particularly Topmind, so I will ignore any critique from them.
The point here is to illustrate that this is one way to represent conventional
accounting with class definitions. It is not the only way. If someone
chooses to reject the OOP model entirely, I am not interested in arguing
about that point. We can tell time with a digital watch, an analog watch,
or some other instrument. I am one of those throwbacks to a different
time who continues to keep a slide rule handy on his desk.
I show this example to answer your question, not to open up some
inane debate about whether one can create accounting systems
with tables, or some other technology. I hope it illustrates the
fundamental idea in answer to your question.
Topmind. Leave it alone. I will not answer you.
Richard Riehle
Topmind
> I show this example to answer your question, not to open up some
> inane debate about whether one can create accounting systems
> with tables, or some other technology. I hope it illustrates the
> fundamental idea in answer to your question.
>
> Topmind. Leave it alone. I will not answer you.
You originally claimed that our approach was
*superior* IIRC. I guess that means you are backing
down from that claim.
Do I have your permission to gloat now?
>
> Richard Riehle
>
-T-
Andrzej Jan Taramina
wrote:
> grumble grumble
Another insightful post from bottomind. ;-)
....Andrzej
NOTE: Remove Spamicide(tm) before replying!!!
Alfredo Novoa
> Indeed, most object oriented models *are* relational models.
What does *are* mean?
Are most object oriented models based on first order logic?
And where is the relation type generator, and the relational algebra
or calculus?
It would have a lot more sense to me if you would said: object
oriented models are graph based (network) models.
> However,
> purely relational models lack any concept of behavior.
All in relational models is behavior.
For instance when you declare a table like this:
create table x (integer x, primary key(x));
You are specifying a lot of behavior.
The same with other SQL constructions like cascade deletions or
cascade updates.
It is true that SQL is very poor for declaring 'behavioral rules', but
the problem is specific to SQL, not to The Relational Model.
Alphora's Dataphor D4 language is a lot better for 'behavioral
modeling'.
> What OO adds
> to relational models is exactly that -- behavior.
Mapping classes (types) to relations (variables)?
> However, it's important that we separate a few issues. Even in an OO
> application we'll still use regular relational modeling for the
> database.
But a lot of OO designers commits big blunders like trying to map an
OO network design to a relational design.
> Rather, we consider the database to
> be a bunch of data that our applications use to create objects within
> themselves and for their own purposes.
But the objects are yet in the database. Tables are full of objects.
Objects are like nouns and relations like sets of phrases using that
nouns. It is a fundamental distinction.
> When we design our applications we partition their modules based upon
> their behavior.
It is nice for managing the GUI-application code, but all the business
data behavioral rules must reside in the database.
> We create object models that separate one kind of
> behavior from another.
The separation is a lot better if data behavior is in the database and
GUI behavior is in the application code.
Alfredo
Universe
> grumble grumble
> -T-
Good answer. Really supports your hackerish point.
Topmind
> wrote:
>
> > grumble grumble
>
> Another insightful post from bottomind. ;-)
>
That is because we have already been round-and-round
on it and I have been accused of being repetitious.
RCM just views the world and its change-patterns
differently than I do.
RCM does indeed make his designs maintenance-friendly based
on *his perceptions* of how the world tends to change.
I don't question him in this regard. He *is* acting
rationally in that respect (although I wish he
would state his unspoken assumptions in his works.)
I just have a fundimental disagreement WRT how the
world tends to change over time. It gets into the
area of psychology and perception, not so much
how to code.
If we both perceive change differently, then
we will naturally come to different solutions
to making software deal better with change.
A military design is shaped by *perceptions*
of what a *future* threat will look like.
Equiping a military to fight Soviets will
look different than one designed to fight
underground terrorists.
I have described some of my reasoning for
my change assumptions at:
http://geocities.com/tablizer/mellor.htm
>
> ....Andrzej
>
> NOTE: Remove Spamicide(tm) before replying!!!
>
-T-
Topmind
in message news:<hl762vs3g4g2e99ng...@4ax.com>...
>
> > Indeed, most object oriented models *are* relational models.
>
> What does *are* mean?
>
I would tend to disagree with that. OO more closely resembles
the "network databases" of the 1960's, not relational.
It is true that a bunch of cloned objects could resemble a
table, but OO does not guarentee consistent "columns" needed
to form tables. (Nor unique keys, also needed by the
relational model.)
OO is generally a bunch of interlinked dictionaries and indexes
of dictionaries. This is the network model, not relational.
-T-
Topmind
>
> Good answer. Really supports your hackerish point.
>
> Elliott
Hackerish? The network-DB-ish model of OO is far more
hackerish than relational. That is why it was
rejected in the early 70's.
Your song ain't groovy anymore, cat.
-T-
JXStern
wrote:
>> "Uncle Bob (Robert C. Martin)" <u.n.c.l...@objectmentor.com> wrote
>in message news:<hl762vs3g4g2e99ng...@4ax.com>...
>>
>> > Indeed, most object oriented models *are* relational models.
>>
>> What does *are* mean?
>>
>
>I would tend to disagree with that. OO more closely resembles
>the "network databases" of the 1960's, not relational.
What Uncle Bob said was:
> Rather, we consider the database to
>be a bunch of data that our applications use to create objects within
>themselves and for their own purposes.
He's being entirely honest here about the gross misuse by most OO'ers
of the relational database.
He says that he's building a nice relational model to support the
domain *objects* rather than the domain itself.
Frankly, that's probably an overstatement, because typically it
results in flat tables that do not relate to each other in any
interesting ways under the claim that that is all that's needed, since
the objects' internal logic does the rest. Given the premise, I
suppose it's a valid statement. No ad-hod queries are ever planned
for the data, so a further relational normalization is not needed.
Ha! All ad-hoc changes need to be hard-coded instead.
It's a great form of job security, if you can get management to buy
off on it, probably extends the average job to 3x longer than it need
be, and is exponentially worse on large projects, but hey, it's what
all the kids are doing.
J.
John Urberg
> He says that he's building a nice relational model to support the
> domain *objects* rather than the domain itself.
What would you consider to be the difference between domain objects and the
domain itself?
> Frankly, that's probably an overstatement, because typically it
> results in flat tables that do not relate to each other in any
> interesting ways under the claim that that is all that's needed, since
> the objects' internal logic does the rest.
I've seen procedural applications with the same symptoms; it has nothing to do
with OO. You should be arguing instead that any project, OO or otherwise, using
a relational database should have someone on the project who understands how to
design and implement a data model.
Regards,
John Urberg
JXStern
<jur...@my-deja.com> wrote:
>> He says that he's building a nice relational model to support the
>> domain *objects* rather than the domain itself.
>
>What would you consider to be the difference between domain objects and the
>domain itself?
The domain must be the same as itself, the domain objects can be
transformed in any number of ways. They *might* be very similar, but
typically are not because (a) they were not designed with any
cannonical forms in mind, as relational databases generally are, (b)
having various collection widgets and other non-relational widgets at
hand, they tend to violate even 1nf.
>> Frankly, that's probably an overstatement, because typically it
>> results in flat tables that do not relate to each other in any
>> interesting ways under the claim that that is all that's needed, since
>> the objects' internal logic does the rest.
>
>I've seen procedural applications with the same symptoms; it has nothing to do
>with OO. You should be arguing instead that any project, OO or otherwise, using
>a relational database should have someone on the project who understands how to
>design and implement a data model.
Well, I quite agree with that last. However, in effect, I believe
that Uncle Bob's claim constitutes a *recommendation* that, at the
least, there is no great concern in a typical n-tier OO application
that the database's data model relate to the domain rather than the
middle-tier objects.
Have you seen this done in practice?
Joshua Stern
John Urberg
>
> The domain must be the same as itself, the domain objects can be
> transformed in any number of ways. They *might* be very similar, but
> typically are not because (a) they were not designed with any
But if the designer is aware of normalization, isn't it is possible to model
the domain with objects?
> having various collection widgets and other non-relational widgets at
> hand, they tend to violate even 1nf.
How does using collections violate 1NF?
> Well, I quite agree with that last. However, in effect, I believe
> that Uncle Bob's claim constitutes a *recommendation* that, at the
> least, there is no great concern in a typical n-tier OO application
> that the database's data model relate to the domain rather than the
> middle-tier objects.
>
> Have you seen this done in practice?
I've seen just the opposite. Most projects I've been on have had a great
deal of attention paid to the data model and little to the software design.
Regards,
John Urberg
Uncle Bob (Robert C. Martin)
this on (or about) Tue, 14 Jan 2003 21:36:29 GMT, :
>What Uncle Bob said was:
>
>> Rather, we consider the database to
>>be a bunch of data that our applications use to create objects within
>>themselves and for their own purposes.
>
>He's being entirely honest here about the gross misuse by most OO'ers
>of the relational database.
>
>He says that he's building a nice relational model to support the
>domain *objects* rather than the domain itself.
No, actually I was saying the opposite of that. I build a relational
model to support the domain, and translate it into objects within the
various applications that use that data. That translation is
different for each application, because the applications have
different needs.
Topmind
> this on (or about) Tue, 14 Jan 2003 21:36:29 GMT, :
>
> >What Uncle Bob said was:
> >
> >> Rather, we consider the database to
> >>be a bunch of data that our applications use to create objects within
> >>themselves and for their own purposes.
> >
> >He's being entirely honest here about the gross misuse by most OO'ers
> >of the relational database.
> >
> >He says that he's building a nice relational model to support the
> >domain *objects* rather than the domain itself.
>
> No, actually I was saying the opposite of that. I build a relational
> model to support the domain, and translate it into objects within the
> various applications that use that data. That translation is
> different for each application, because the applications have
> different needs.
>
I actually agree with this in part. However, it is *tasks*
that have different needs more so than "application".
IOW, the granularity of relativism is smaller than
the application in a good many cases. The query ability
of relational (which excels that of NDB's and their
OODB cousins) greatly facilates such localization.
Thus I use local queries for custom adaptation
while you use app-level class interfaces. (Of course
similar parts of queries, if encountered, can be
factored to shared routines.)
OO lacks a division unit between "class" and "application",
which makes OO hard to navigate because you have
a jillion classes. Tasks tend to be larger than
classes, so there are fewer of them. Plus, you know
what they are: tasks and only tasks (for the most
part). Classes can be nouns, verbs, "managers", adaptors,
and all kinds of funny stuff, all floating around
together. It lacks a clear larger-scale division
that P/R has: nouns in the DB and task units in the
code.
OO is like a lot of surface streets but no main
highways. You go from surface streets to
State-level (application) in unit size, with nothing
in-between.
>
> Robert C. Martin | "Uncle Bob"
-T-
JXStern
wrote:
>OO lacks a division unit between "class" and "application",
>which makes OO hard to navigate because you have
>a jillion classes.
OO does not have an inherent division, but there seems to be a growing
practice of creating a set of driver classes based on use cases, which
effects just exactly what you are talking about.
J.
JXStern
<u.n.c.l...@objectmentor.com> wrote:
>>> Rather, we consider the database to
>>>be a bunch of data that our applications use to create objects within
>>>themselves and for their own purposes.
>>
>>domain *objects* rather than the domain itself.
>
>No, actually I was saying the opposite of that. I build a relational
>model to support the domain, and translate it into objects within the
>various applications that use that data. That translation is
>different for each application, because the applications have
>different needs.
In that case, I apologize for misreading you.
Joshua Stern
JXStern
<jur...@my-deja.com> wrote:
>But if the designer is aware of normalization, isn't it is possible to model
>the domain with objects?
It's possible, but the problem is with the antecedent "if".
>> having various collection widgets and other non-relational widgets at
>> hand, they tend to violate even 1nf.
>
>How does using collections violate 1NF?
Constitutes a repeating group, and/or explicit links. It *can* be
unpacked back to a cannonical database form -- in fact, it has to be
in order to be stored in an RDBMS as anything but a blob. But you're
then translating between two different physical designs, which is
still doing unnecessary work, the way I look at it.
>I've seen just the opposite. Most projects I've been on have had a great
>deal of attention paid to the data model and little to the software design.
Have you seen that in different shops? In the modern world of the OO
afficionado, there is generally some kind of UML or at least class
hierarchy design. I've seen some two-tier shops that were pretty good
on the database side and just sort of hacked up the client side, that
was the standard Microsoft model before they went n-tier, but that's
going on years ago now. I rather like that approach, actually (well,
a little design on the software side helps, but it's usually pretty
standardized so a little is all that's needed).
Joshua Stern
John Urberg
> >> having various collection widgets and other non-relational widgets at
> >> hand, they tend to violate even 1nf.
> >
> >How does using collections violate 1NF?
>
> Constitutes a repeating group, and/or explicit links. It *can* be
> unpacked back to a cannonical database form -- in fact, it has to be
> in order to be stored in an RDBMS as anything but a blob. But you're
> then translating between two different physical designs, which is
> still doing unnecessary work, the way I look at it.
So I have a invoice and invoice_line tables. The invoice_line has a
foreign key to invoice (isn't a foreign key an explict link?). I model
that in OO as an Invoice that contains a collection of InvoiceLine.
Translation is done in one spot either with SQL or an O/R mapper tool. I
now have my domain model represented in my code. Don't you think having
the domain model in the code makes it easier to reason about (not to
mention maintain) than a bunch of subroutines that make ad hoc queries
against the database?
> >I've seen just the opposite. Most projects I've been on have had a
great
> >deal of attention paid to the data model and little to the software
design.
>
> Have you seen that in different shops?...
Yup. But most of my experience has been using PowerBuilder. All 2 tier
except one. Every project I've worked on has said they were doing OO
development because PB supported OO. I bet you can guess what the code
really looked like...
Regards,
John Urberg
Topmind
IOW a "task".
"The more complicated an OO systems gets, the more it tends
to (poorly) reinvent procedural/relational techniques." -topmind-
>
> J.
>
>
-T-
Topmind
news:<MPG.188c0f9d3...@news.earthlink.net>...
> > > "billg" <bi...@aol.net> might (or might not) have written this on (or
> > > about) Sat, 11 Jan 2003 19:59:22 -0500, :
> > >
> > > >Can the unique problem domains of the business world be usefully modeled
> > > >with Object Technology?
> > >
> > > that is universally applicable to all kinds of software. For the most
> > > part, OO is a technique for structuring source code so as to reduce
> > > coupling.
> >
> >
> > reduce. Coupling is something to *manage*. For
> > coupling has GOOD sides too.
>
> real life coupling). The good kind is "cohering".
Are you saying that if a relationship turns out to be
bad, it is *renamed* to "coupling", but named to
"cohering" if good?
Sounds like politics.
>
> > For one, it allows you
> > to keep things in a group or package such that you don't have
> > to manage each little element by itself. IOW, coat-tails.
> > Classes and modules and routines and inheritence and
> > "types" and schemas are all concepts that "package"
> > things togther. IOW, coupling.
> >
> > A breif-case couples a bunch of stuff together so that
> > we don't have to carry each item by itself. If we need
> > our cellphone often, then we perhaps want to decouple
> > it from the breif-case (take it out) for a while, for
> > instance.
> >
> > In a nut-shell, coupling is good when it fits requirement
> > change patterns and bad when it does not.
> >
> > Besides, coupling is kind of a vague term which
> > comes in all kinds of shapes and sizes, some of
> > them not readily appearent. Polymorphism has
> > coupling in it too. OO philosophy is *not* couple-free.
> > (Seasoned comp.ob'ers know this story already so I
> > won't repeat it.)
> >
> > It all comes down the estimating future change
> > patterns and finding the balance of coupling to
> > best fit it. That is the key fish in these debates,
> > not coupling itself.
>
> Right. And the best way to estimate future change patterns is to let
> historic change patterns influence your codes partitioning and
> abstraction.
Which is precisely what I do, and the result is usually
not OO.
OO is only superior if the world changes in a tree-shape
or adds new functionality on the granularity and divisions
of "subtypes" of mutually-exclusive categories.
But, it does not in my observation. These "categories"
tend to be relativistic, dynamic, and often grow
orthogonal over time.
"Absolute taxonomy" is a flaw of many OO methodologies.
There is no such thing. (And if it is meant as a local
adaption, then OO lacks modules to contain them.)
Most the world is a big graph (network), not a tree.
Now if you agree with me on this, then either we use
an NDB-like approach or RDB. History has twice
pissed on NDB's, so I think we should burry them
for good (barring a new revolutionary breakthru in them).
>
> --
> Phlip
-T-
JXStern
<jur...@my-deja.com> wrote:
>So I have a invoice and invoice_line tables. The invoice_line has a
>foreign key to invoice (isn't a foreign key an explict link?).
No, it's not.
> I model
>that in OO as an Invoice that contains a collection of InvoiceLine.
Typically this is done as a compound with repeating group of lines, or
as a hierarchy -- which it actually is, and the relational
representation is perhaps not truly optimal, but there it is!
>Translation is done in one spot either with SQL or an O/R mapper tool. I
>now have my domain model represented in my code. Don't you think having
>the domain model in the code makes it easier to reason about (not to
>mention maintain) than a bunch of subroutines that make ad hoc queries
>against the database?
Yes, I think it can be done well. As long as you stay with simple
cases, it probably is done well. When things get complex, that's when
the code gets funky and the relational discipline kicks in.
But in general, I am not at all certain that having the domain model
in code is a good idea, when it already exists in the database.
That's not a "no", that's an "I have seen it done both ways, and I am
not certain which I prefer".
>> Have you seen that in different shops?...
>
>Yup. But most of my experience has been using PowerBuilder. All 2 tier
>except one. Every project I've worked on has said they were doing OO
>development because PB supported OO. I bet you can guess what the code
>really looked like...
Well, don't even get me going on PB. I had occassion to be
reintroduced to PB 6.x with its OO library, a couple of years ago.
Hey, PB 1.x/2.x was hot stuff, back when, but PB 6+ ... yikes!
Most of the really bad stuff I've seen is when you go to three+ tiers.
J.
JXStern
Well OK, and maybe it only took fifteen years to get this far, but at
least it stops suffering from the precise problem you were describing.
J.
Topmind
>
> > >> having various collection widgets and other non-relational widgets at
> > >> hand, they tend to violate even 1nf.
> > >
> > >How does using collections violate 1NF?
> >
> > Constitutes a repeating group, and/or explicit links. It *can* be
> > unpacked back to a cannonical database form -- in fact, it has to be
> > in order to be stored in an RDBMS as anything but a blob. But you're
> > then translating between two different physical designs, which is
> > still doing unnecessary work, the way I look at it.
>
> So I have a invoice and invoice_line tables. The invoice_line has a
> foreign key to invoice (isn't a foreign key an explict link?). I model
> that in OO as an Invoice that contains a collection of InvoiceLine.
> Translation is done in one spot either with SQL or an O/R mapper tool. I
> now have my domain model represented in my code. Don't you think having
> the domain model in the code makes it easier to reason about (not to
> mention maintain) than a bunch of subroutines that make ad hoc queries
> against the database?
Could you please clarify "easier to reason about"?
You also make it sound like "ad-hoc" is bad. Is it?
Besides, what does ad-hoc mean in this context anyhow?
>
> > >I've seen just the opposite. Most projects I've been on have had a
> great
> > >deal of attention paid to the data model and little to the software
> design.
> >
> > Have you seen that in different shops?...
>
> Yup. But most of my experience has been using PowerBuilder. All 2 tier
> except one. Every project I've worked on has said they were doing OO
> development because PB supported OO. I bet you can guess what the code
> really looked like...
....somebody else's definition of OO besides yours.
OoDefinitionID++
INTEGER OVERFLOW ERROR
>
> Regards,
> John Urberg
>
-T-
Topmind
> <jur...@my-deja.com> wrote:
> >So I have a invoice and invoice_line tables. The invoice_line has a
> >foreign key to invoice (isn't a foreign key an explict link?).
>
> No, it's not.
>
> > I model
> >that in OO as an Invoice that contains a collection of InvoiceLine.
>
> Typically this is done as a compound with repeating group of lines, or
> as a hierarchy -- which it actually is, and the relational
> representation is perhaps not truly optimal, but there it is!
But not all access approaches are going to be hierarchical,
I would note. For example, if you are doing sales-by-product
tallies, then you only visit the details, ignoring the
"invoice heading" perhaps. (Lets assume by ship date
instead of order date.) Or you visit the details first
in order to find the "parent". "Who ordered X?" type of
queries. It is just another one-to-many
relationship rather than a "hierarchy".
>
> >Translation is done in one spot either with SQL or an O/R mapper tool. I
> >now have my domain model represented in my code. Don't you think having
> >the domain model in the code makes it easier to reason about (not to
> >mention maintain) than a bunch of subroutines that make ad hoc queries
> >against the database?
>
> Yes, I think it can be done well. As long as you stay with simple
> cases, it probably is done well. When things get complex, that's when
> the code gets funky and the relational discipline kicks in.
>
> But in general, I am not at all certain that having the domain model
> in code is a good idea, when it already exists in the database.
> That's not a "no", that's an "I have seen it done both ways, and I am
> not certain which I prefer".
C2 Wiki calls it OnceAndOnlyOnce.
The usual OO justification is that one needs to "adapt" the view
to the application. However, I find that it needs to be adapted
at a smaller granularity than just app--the task level,
since different parts of the application need different
views. Thus, the local adaptation argument does not ring
sound with me. Larger OO apps start to get awash in global
adaptors (or many adaptor methods) if you carry that approach.
-T-
Topmind
Which problem is that? I described lots of stuff.
>
> J.
>
>
-T-
Paul Sinnett
> real life coupling). The good kind is "cohering".
Coupling and cohesion are separate concepts in programming. Cohesion
refers to the internal connections and coupling refers to the external
connections. There are good and bad forms of both.
Topmind
What is "internal" and "external" are probably fuzzy
and language-dependent, I would guess.
-T-
JXStern
wrote:
This:
>> >> >OO lacks a division unit between "class" and "application",
>> >> >which makes OO hard to navigate because you have
>> >> >a jillion classes.
You have the division, and the unwieldy tree of classes is grouped
relatively cleanly by doing a where-used within the static code under
each task class.
J.
Universe
Actually they are flip sides of a design coin that should be handled
properly in dialectical opposition. That is at least when the 2 are
juxtaposed correctly as is traditionally done. What we strive to achieve
for optimal system design is:
Loose Coupling with High Cohesion
[Loose Coupling<=>High Cohesion]
It shouldn't take much imagination to realize that properly doing one
strengthens the other. And versa vice. ;-}
And what you gain by achieving both optimally are systems that are
flexible yet robust, systems that facilitate modular reuse, systems that
have very good separation of concerns, etc and so on.
Universe
Truly the real significance of the whole dialectic - internal<=>external -
and real meaning of each aspect in the opposition are context dependent.
And of course what is internal in one context is at the same time external
in another and "versa vice".
Richard Riehle
> Truly the real significance of the whole dialectic - internal<=>external -
> and real meaning of each aspect in the opposition are context dependent.
>
> And of course what is internal in one context is at the same time external
> in another and "versa vice".
Elliot,
I am reminded of the famous Klein Bottle from Topology. It has no true
inside or true outside, yet it would be, if it were possible to construct
one, a three-dimensional figure that has only one dimension, mathematically.
Consider this sentence to be an extended smiley.
Richard Riehle
Topmind
I cannot parse this sentence.
>
> J.
>
-T-
JXStern
wrote:
>> You have the division, and the unwieldy tree of classes is grouped
>> relatively cleanly by doing a where-used within the static code under
>> each task class.
>
>I cannot parse this sentence.
Probably not worth the effort to do so anyway, never mind.
J.
S Perryman
news:3E25EF7B...@btinternet.com...
The concepts are not totally orthogonal. There is a linkage between
them. For example, applying cohesion techniques to ADT interfaces
results in clients that can be more loosely coupled.
Regards,
Steven Perryman
S Perryman
news:MPG.188f4c6c2...@news.earthlink.net...
> "Absolute taxonomy" is a flaw of many OO methodologies.
> There is no such thing. (And if it is meant as a local
> adaption, then OO lacks modules to contain them.)
> Most the world is a big graph (network), not a tree.
Once again (yawn) :
In OO, we build type *lattices* .
A lattice is a realisation of the graph concept.
A tree is a degenerate case of a graph, with simpler behaviour.
Another example of your complete misunderstanding of OO.
Regards,
Steven Perryman
Paul Sinnett
>>> (unlike real life coupling). The good kind is "cohering".
>
>> Coupling and cohesion are separate concepts in programming.
>> Cohesion refers to the internal connections and coupling refers to
>> the external connections. There are good and bad forms of both.
>
> Actually they are flip sides of a design coin that should be handled
> properly in dialectical opposition.
The point is that cohesion is not good coupling, and coupling is not bad
cohesion. There are good and bad forms of both and they do not equate to
each other. You can have tight or loose coupling and high or low
cohesion in any combination.
Alfredo Novoa
> > >He says that he's building a nice relational model to support the
> > >domain *objects* rather than the domain itself.
> >
> > No, actually I was saying the opposite of that. I build a relational
> > model to support the domain, and translate it into objects within the
> > various applications that use that data. That translation is
> > different for each application, because the applications have
> > different needs.
It is not as bad as the opposite, but still requires the fundamentally
flawed O-R mapping practice.
http://searchdatabase.techtarget.com/ateQuestionNResponse/0,289625,sid13_cid486169_tax292527,00.html
> Thus I use local queries for custom adaptation
> while you use app-level class interfaces. (Of course
> similar parts of queries, if encountered, can be
> factored to shared routines.)
Similar parts of queries can be 'factored' to views.
Regards,
Alfredo
Topmind
True, but I have a problem with that sometimes. Sometimes
the duplication may not be universal, but just app-wide (so far).
RDBMS views tends to be global.
However, views sometimes factor better than SQL
sub-strings because of the flaws in SQL itself.
(Relational alternatives like BS12 seemed better
for that because they relied on references instead
of nesting. Damned trees have polluted SQL also :-)
>
> Regards,
> Alfredo
>
-T-
Topmind
> news:MPG.188f4c6c2...@news.earthlink.net...
>
> > "Absolute taxonomy" is a flaw of many OO methodologies.
> > There is no such thing. (And if it is meant as a local
> > adaption, then OO lacks modules to contain them.)
>
> > Most the world is a big graph (network), not a tree.
>
> Once again (yawn) :
>
> In OO, we build type *lattices* .
> A lattice is a realisation of the graph concept.
Perhaps, but is it superior to relational
approaches? Those OO lattices are "CODYSAL warmed over"
as someone once put it. [Spelling?]
> A tree is a degenerate case of a graph, with simpler behaviour.
It is *only* simpler if it models something that is *actually*
a tree. If not, then the workarounds are worse than it would
be if tossing the tree.
Hammers, nails, and wood are simple. However, that does not mean
that using only them will make every structure simpler.
>
> Another example of your complete misunderstanding of OO.
YOUR version of OO, which of course differs from
everybody else's.
Pinning down OO is like nailing jello to a cloud.
>
>
> Regards,
> Steven Perryman
>
>
-T-
Universe
> >>> Right. Part of the definition of "coupling" is that it is bad
> >>> (unlike real life coupling). The good kind is "cohering".
> >
> >> Coupling and cohesion are separate concepts in programming.
> >> Cohesion refers to the internal connections and coupling refers to
> >> the external connections. There are good and bad forms of both.
> >
> > Actually they are flip sides of a design coin that should be handled
> > properly in dialectical opposition.
> The point is that cohesion is not good coupling,
*Strong intra-module* cohesion (coherence) is good coupling within what
should be "cohered", I think.
> and coupling is not bad cohesion.
*Loose inter-module* coupling is not bad cohesion, I can agree with.
> There are good and bad forms
> of both and they do not equate to
> each other. You can have tight or loose coupling and high or low
> cohesion in any combination.
I think if we get beyond simply mentioning "coherence" and "coupling" to:
* Loose inter-module Coupling<=>Strong intra-module Coherence *
we can gain more insight on these matters.
Topmind
Bummer, because "task class" made my ears perk up.
>
> J.
>
-T-
Warren Zeigler
message > Object technology is a software implementation and design
technology
> that is universally applicable to all kinds of software. For the most
> part, OO is a technique for structuring source code so as to reduce
> coupling.
No, YOU use objects that way.
There are MANY uses for object technology. Don't cast everyone else into
your world view. You KNOW that you have developed much of the work in this
area (object/dependencies). This does not invalidate other peoples' work.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
news:e4330f45.03011...@posting.google.com...
> Problems domains of the business world are better modeled with
> relational designs.
I would say that this is VERY strange.
Relational theory was not developed for business modeling. It is a
CONTORTION of early business models, designed for data storage in a flexible
manner. Specific goals include no duplication of data and easy ad-hoc
reporting.
Object modeling was designed for business modeling, and, in fact, is used by
many non-developers for this purpose. NO ONE outside of software developers
use relational theory.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
S Perryman
> > In OO, we build type *lattices* .
> > A lattice is a realisation of the graph concept.
> Perhaps, but is it superior to relational approaches?
For what ?? For everything ?? Some things ?? Most things ??
> Those OO lattices are "CODYSAL warmed over"
> as someone once put it. [Spelling?]
Yawn (again) .
> > A tree is a degenerate case of a graph, with simpler behaviour.
> It is *only* simpler if it models something that is *actually*
> a tree. If not, then the workarounds are worse than it would
> be if tossing the tree.
ROTFLMAO.
No, it is simpler when something can be *viewed* as a tree.
As you seem to be so incapable of understanding, I use *lattices* .
When something in that lattice can be viewed as a tree, I view it as
a tree.
But I always have the lattice regardless.
The lattice is always more powerful than the tree, because the latter
is a *degenerate* case of the former.
> Hammers, nails, and wood are simple. However, that does not mean
> that using only them will make every structure simpler.
>
> >
> > Another example of your complete misunderstanding of OO.
>
> YOUR version of OO, which of course differs from
> everybody else's.
And your version relates to nobodys' .
That is because you have never used OO on a development project.
All you can do is "observe" based on toy examples discussed here.
Toy examples that when they don't support the rhetoric you spout,
spiral off into "based on my change patterns" and so on (readers know
the usual tedious rubbish) .
Regards,
Steven Perryman
Topmind
> > relational designs.
>
Note that I did not say this.
>
> I would say that this is VERY strange.
>
> Relational theory was not developed for business modeling. It is a
> CONTORTION of early business models, designed for data storage in a flexible
> manner. Specific goals include no duplication of data and easy ad-hoc
> reporting.
>
> Object modeling was designed for business modeling,
No, it was designed for *physical* modeling. That is
what Simula was used for. Physical modeling is about
recreating or simulating the world *as-is* rather than
*replace* the physical world, which is what biz apps
tend to do. Biz modeling is office automation, physical
modeling would *simulate* physical paper, secretaries
walking around filing things, etc.
> and, in fact, is used by
> many non-developers for this purpose. NO ONE outside of software developers
> use relational theory.
I have yet to see non-IT people writing classes. What gives?
>
> --
> Warren Zeigler
> wzei...@UnderstandingObjects.com
>
-T-
Martin Sandin
...
> Indeed, most object oriented models *are* relational models. However,
> purely relational models lack any concept of behavior. What OO adds
> to relational models is exactly that -- behavior.
But couldn't exactly that be the problem of OO, this coupling of behaviour
and data? Is it meaningful to talk about that as a problem? Just this moment
it feels like all these adapter classes, singeltons, mixins, aspects
(hyperslices or what you prefer), all try to solve this problem, that OO
invites one to couple behaviour and data tighter than what is healthy.
Just a thought, and probably not an original one =)
Martin
http://come.to/vague
Topmind
> news:MPG.18908488b...@news.earthlink.net...
>
> > > In OO, we build type *lattices* .
> > > A lattice is a realisation of the graph concept.
>
> > Perhaps, but is it superior to relational approaches?
>
> For what ?? For everything ?? Some things ?? Most things ??
Interesting question. But, past discusssions about
where to use what, when, and why never got very
far. Nobody could agree on anything (inside and
outside of OO groups).
>
> > Those OO lattices are "CODYSAL warmed over"
> > as someone once put it. [Spelling?]
>
> Yawn (again) .
>
>
> > > A tree is a degenerate case of a graph, with simpler behaviour.
>
> > It is *only* simpler if it models something that is *actually*
> > a tree. If not, then the workarounds are worse than it would
> > be if tossing the tree.
>
> ROTFLMAO.
>
> No, it is simpler when something can be *viewed* as a tree.
> As you seem to be so incapable of understanding, I use *lattices* .
> When something in that lattice can be viewed as a tree, I view it as
> a tree.
Gee, you almost sound like a relationalist. Inheritance
is a hard-wired tree, not a virtual tree.
>
> But I always have the lattice regardless.
> The lattice is always more powerful than the tree, because the latter
> is a *degenerate* case of the former.
>
Good start. You graduated from HDB to NDB. You are just
missing the next step up to RDB.
>
> > Hammers, nails, and wood are simple. However, that does not mean
> > that using only them will make every structure simpler.
> >
> > >
> > > Another example of your complete misunderstanding of OO.
> >
> > YOUR version of OO, which of course differs from
> > everybody else's.
>
> And your version relates to nobodys' .
> That is because you have never used OO on a development project.
> All you can do is "observe" based on toy examples discussed here.
No, I also obsverse people playing around with OO in
productive code and making odd, contorted messes.
>
> Toy examples that when they don't support the rhetoric you spout,
> spiral off into "based on my change patterns" and so on (readers know
> the usual tedious rubbish) .
>
Much of OO justification depends on assumptions about
change patterns. You cannot escape it.
>
> Regards,
> Steven Perryman
>
-T-
S Perryman
SP> In OO, we build type *lattices* .
SP> A lattice is a realisation of the graph concept.
T> Perhaps, but is it superior to relational approaches?
> > For what ?? For everything ?? Some things ?? Most things ??
> Interesting question. But, past discusssions about
> where to use what, when, and why never got very
> far. Nobody could agree on anything (inside and
> outside of OO groups).
> > No, it is simpler when something can be *viewed* as a tree.
> > As you seem to be so incapable of understanding, I use *lattices* .
> > When something in that lattice can be viewed as a tree, I view it as
> > a tree.
> Gee, you almost sound like a relationalist. Inheritance
> is a hard-wired tree, not a virtual tree.
ROTLFMAO.
Obviously you are incapable of understanding that a tree is a specific
case of a lattice. And thus the former cannot do everything the latter
can, and the latter can do everything the former can.
You still don't get it. Methinks you are mentally unequipped in some way.
Certainly enough not to be able to engage with us on this topic.
> > And your version relates to nobodys' .
> > That is because you have never used OO on a development project.
> > All you can do is "observe" based on toy examples discussed here.
> No, I also obsverse people playing around with OO in
> productive code and making odd, contorted messes.
Whose OO code have you observed ?? Which systems ??
To hang you with your own rhetoric : put the code where your mouth is.
Point us to this mythical code so we can have a look at it.
> > Toy examples that when they don't support the rhetoric you spout,
> > spiral off into "based on my change patterns" and so on (readers know
> > the usual tedious rubbish) .
> Much of OO justification depends on assumptions about
> change patterns. You cannot escape it.
Fine.
Then all you have is disagreement about change patterns. We can live
with that. But there is nothing more for you to argue regarding "P/R"
vs OO.
But again, you seem to be mentally unequipped to process this fact.
Why you have spent N yrs in this specific newsgrp spouting
crap beyond this simple fact ??
Looks like symptoms of a more serious mental problem to me ...
Regards,
Steven Perryman
Mikito Harakiri
news:b061br$lsu1t$3...@ID-75294.news.dfncis.de...
> In OO, we build type *lattices* .
> A lattice is a realisation of the graph concept.
> A tree is a degenerate case of a graph, with simpler behaviour.
First, let's confirm that we use identical lattice definition. Because many
programmers call any Directed Acyclic Graph (DAG) a lattice. Here is
MathWorld definition:
http://mathworld.wolfram.com/Lattice.html
Therefore, every lattice is a DAG, but there are some DAGs that are not
lattices.
Why types are organized into lattices? What prevents us to have type
"hierarchy" like this:
class B1;
class B2;
class D1 extends B1, B2
class D2 extends B1, B2
(This is a DAG which is not a lattice).
Warren Zeigler
wzei...@UnderstandingObjects.comnews:MPG.18908b845...@news.earthlink.net...
> > Object modeling was designed for business modeling,
>
>
> No, it was designed for *physical* modeling. That is
> what Simula was used for. Physical modeling is about
> recreating or simulating the world *as-is* rather than
> *replace* the physical world, which is what biz apps
> tend to do. Biz modeling is office automation, physical
> modeling would *simulate* physical paper, secretaries
> walking around filing things, etc.
>
>
> > and, in fact, is used by
> > many non-developers for this purpose. NO ONE outside of software
developers
> > use relational theory.
>
> I have yet to see non-IT people writing classes. What gives?
I am talking about modeling, differentiating that from coding.
The UML is used in business modeling outside of software development.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Topmind
> news:MPG.18908db4b...@news.earthlink.net...
>
> SP> In OO, we build type *lattices* .
> SP> A lattice is a realisation of the graph concept.
>
> T> Perhaps, but is it superior to relational approaches?
>
> > > For what ?? For everything ?? Some things ?? Most things ??
>
> > Interesting question. But, past discusssions about
> > where to use what, when, and why never got very
> > far. Nobody could agree on anything (inside and
> > outside of OO groups).
>
>
> > > No, it is simpler when something can be *viewed* as a tree.
> > > As you seem to be so incapable of understanding, I use *lattices* .
> > > When something in that lattice can be viewed as a tree, I view it as
> > > a tree.
>
> > Gee, you almost sound like a relationalist. Inheritance
> > is a hard-wired tree, not a virtual tree.
>
> ROTLFMAO.
>
> Obviously you are incapable of understanding that a tree is a specific
> case of a lattice. And thus the former cannot do everything the latter
> can, and the latter can do everything the former can.
"Lattice" is not part of OO.
> > > Toy examples that when they don't support the rhetoric you spout,
> > > spiral off into "based on my change patterns" and so on (readers know
> > > the usual tedious rubbish) .
>
> > Much of OO justification depends on assumptions about
> > change patterns. You cannot escape it.
>
> Fine.
> Then all you have is disagreement about change patterns. We can live
> with that. But there is nothing more for you to argue regarding "P/R"
> vs OO.
If the change perceptions are key, then they are key.
....
> But again, you seem to be mentally unequipped to process this fact.
You wouldn't know a fact if it bit you in the ass.
> Why you have spent N yrs in this specific newsgrp spouting
> crap beyond this simple fact ??
>
> Looks like symptoms of a more serious mental problem to me ...
For the sake of argument, suppose I was crackers?
Why tell me this? How many cracked people were fixed
by telling them that?
Some have drinking problems, some of Obsessive Anti-OO
problems.
>
> Regards,
> Steven Perryman
>
-T-
Topmind
I vaguely remember a big discussion about that here (comp.object).
IIRC, a good many felt that UML was *not* well suited for customer
interaction. Simplifed combinations of flow-charts and
data flow diagrams seem the most effective from my
experience. Sample reports and screens are also
effective.
(Then again, UML can be flow charts and DFD's if you
go with the wider definition.)
Universe
> The UML is used in business modeling outside of software development.
You need to read and get out a *lot* more.
Universe
Apology. It seems you meant UML is additionally used outside of sw
development.
Elliott
Warren Zeigler
> I vaguely remember a big discussion about that here (comp.object).
> IIRC, a good many felt that UML was *not* well suited for customer
> interaction. Simplifed combinations of flow-charts and
> data flow diagrams seem the most effective from my
> experience. Sample reports and screens are also
> effective.
Many of the people here are not in a position to have used the UML for this
purpose. The fact is, it is used and it works.
--
Warren Zeigler
wzei...@UnderstandingObjects.com
Warren Zeigler
--
Warren Zeigler
wzei...@UnderstandingObjects.com
"Universe" <univ...@radixundo.net> wrote in message
news:b07eba$d56$2...@news1.radix.net...
Paul Sinnett
>
> *Strong intra-module* cohesion (coherence) is good coupling within
> what should be "cohered", I think.
Cohesion and coupling refer to different things in the same context.
That is, in the context of modules, cohesion refers to relatedness
within a module whereas coupling refers to connections between modules.
In the context of functions, cohesion refers to relatedness within a
function, and coupling refers to connections between functions.
You suggest, I think, that loose coupling in the function context
equates to high cohesion within that function's module. That is wrong.
They are certainly related, but they are not the same.
Coupling is a measure of the number and type of connections between
things. If something has loose coupling it has few and simple
connections. If something has tight coupling it has many and complex
connections.
Cohesion measures the relatedness of the parts within a unit. If the
parts of a unit are mostly related the unit has high cohesion. If the
parts of a unit are mostly unrelated the unit has low cohesion.
Applying this to functions and modules:
If a module contains mostly unrelated functions, that module has low
cohesion. Tight or loose coupling between the functions within the
module does not change that module's cohesion.
If a module contains mostly related functions, that module has high
cohesion. Tight or loose coupling between the functions within the
module does not change that module's cohesion.
Earlier I said that although they are not the same they are related.
They are related because related functions tend to require fewer and
simpler connections, and unrelated functions tend to require more and
nastier connections. Thus high cohesion tends to produce loose coupling
and so on.
This is how I understand the definitions of coupling and cohesion from a
structured design perspective.
Uncle Bob (Robert C. Martin)
written this on (or about) Thu, 16 Jan 2003 17:11:53 GMT, :
Warren,
Have you notice that you capslock key has been sticking lately?
Frankly, though I have heard lots of hype and many claims about the
benefits of OO, the only ones that I can personally verify are those
that have to do with improving the structure of source code. I happen
to think that those are very significant benefits and so I'm not
pleased when I see the other, non-verifiable, benefits raised.
Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |
"...a member of my local hiking club is a
nudist. I once asked him if he ever hiked in the nude. He responded
that he was a nudist, he wasn't nuts."
-- Daniel Parker
Topmind
> written this on (or about) Thu, 16 Jan 2003 17:11:53 GMT, :
>
> >"Uncle Bob (Robert C. Martin)" <u.n.c.l...@objectmentor.com> wrote in
> >message > Object technology is a software implementation and design
> >technology
> >> that is universally applicable to all kinds of software. For the most
> >> part, OO is a technique for structuring source code so as to reduce
> >> coupling.
> >
> >
> >No, YOU use objects that way.
> >
> >There are MANY uses for object technology. Don't cast everyone else into
> >your world view. You KNOW that you have developed much of the work in this
> >area (object/dependencies). This does not invalidate other peoples' work.
>
> Warren,
>
> Have you notice that you capslock key has been sticking lately?
>
> Frankly, though I have heard lots of hype and many claims about the
> benefits of OO, the only ones that I can personally verify are those
> that have to do with improving the structure of source code. I happen
> to think that those are very significant benefits and so I'm not
> pleased when I see the other, non-verifiable, benefits raised.
>
Frankly, Robert, your evidence is no more solid than
any other I have seen. At least I seem to understand
your reasoning, from a technique side at least,
so I will give you credit for sufficient clarity.
But your reasoning has certain *assumptions*
about change patterns behind them which I don't agree with.
You said something like, "well my observations point
that way". All I can say is that it contradicts
my observations of human processes, politics,
and business change patterns. We just see the
world differently.
(Perhaps someday we can explore these fuzzier
sides more.)
Most evidence I have encountered
in which the author/originator
is willing to pursue to the finish have *similar*
underpinnings, which are root psychological
perception-related issues.
I suppose an analogy from another field would
be supply-side economics versus demand-side
economics. Who is "right" depends on base
assumptions about human nature. Both sides
get the "math" right based on these assumptions,
but their math still relies on key assumptions
that are in the realm of psychology, socialogy and
individual perceptions.
IOW, the logic and math runs into the wall of
human behavior. I don't question your "proofs",
just your givens, and it is similar with other
evidence presented.
If you want your works to be more academically
rigid, I would suggest you explore these "givens"
more.
>
> Robert C. Martin | "Uncle Bob"
-T-
S Perryman
news:vtCV9.14$Mb6...@news.oracle.com...
> "S Perryman" <q...@q.com> wrote in message
> news:b061br$lsu1t$3...@ID-75294.news.dfncis.de...
> > In OO, we build type *lattices* .
> > A lattice is a realisation of the graph concept.
> > A tree is a degenerate case of a graph, with simpler behaviour.
>
> First, let's confirm that we use identical lattice definition. Because
many
> programmers call any Directed Acyclic Graph (DAG) a lattice. Here is
> MathWorld definition:
>
> http://mathworld.wolfram.com/Lattice.html
>
> Therefore, every lattice is a DAG, but there are some DAGs that are not
> lattices.
Ok, you don't like my use of lattice (FYI, it is embedded in my head since
1987 from the Stefik/Bobrow paper in which they call OO type graphs
"lattices" .
> Why types are organized into lattices? What prevents us to have type
> "hierarchy" like this:
> class B1;
> class B2;
>
> class D1 extends B1, B2
> class D2 extends B1, B2
> (This is a DAG which is not a lattice).
No need to prevent such type hierarchies.
In fact some prog envs allow the above and still apply poset functions to
ensure all is well. For example, CLOS when dealing with multiple inheritance
applies a topological ordering to ensure correct op resolution/invocation
(your example would be { B1, B2, D1, D2 } ) .
That aside, topblind still doesn't understand the difference between a tree
and a graph.
Regards,
Steven Perryman
S Perryman
> > Obviously you are incapable of understanding that a tree is a specific
> > case of a lattice. And thus the former cannot do everything the latter
> > can, and the latter can do everything the former can.
> "Lattice" is not part of OO.
You cannot tell the difference between a (mathematical) graph and a tree.
You cannot understand the fact that the former is a more general case
of the latter, and is therefore more powerful in concept and use.
You cannot understand the fact that because OO allows multiple
inheritance, we can build type graphs. If we can build type graphs, then
by definition we are *not forced to fit things into trees* .
Which kills a big part of your tedious rhetoric stone-dead.
> > Why you have spent N yrs in this specific newsgrp spouting
> > crap beyond this simple fact ??
> > Looks like symptoms of a more serious mental problem to me ...
> For the sake of argument, suppose I was crackers?
> Why tell me this? How many cracked people were fixed
> by telling them that?
> Some have drinking problems, some of Obsessive Anti-OO
> problems.
Indeed.
And judging by google, a person A who posts *6* times as much over
a 3 yr period as a person B on comp.object, where person B posts as
an advocate and positive contributor, and person A offers nothing other
than their rabid hatred, IMHO we can assume that person A indeed
has "obsessive anti-OO" problems.
Exercise for the reader: who is A and B. :-)
Thank you for your honesty and courage in admitting the problem and
your recognition of the fact you are unlikely to be cured of it. You are
to be commended IMHO.
Regards,
Steven Perryman
Costin Cozianu
>
>
>>"Absolute taxonomy" is a flaw of many OO methodologies.
>>There is no such thing. (And if it is meant as a local
>>adaption, then OO lacks modules to contain them.)
>
>
>>Most the world is a big graph (network), not a tree.
>
>
> Once again (yawn) :
>
No, we don't. Maybe you think you do.
> A lattice is a realisation of the graph concept.
yawn
> A tree is a degenerate case of a graph, with simpler behaviour.
yawn
Further down the road you wrote:
"Obviously you are incapable of understanding that a tree is a specific
case of a lattice."
Of course, we're all incapable of understanding such non-sense.
>
> Another example of your complete misunderstanding of OO.
>
I'm affraid that's an example of your complete misunderstanding of
Mathematics.
>
> Regards,
> Steven Perryman
>
>
Costin Cozianu
Sean Winship
> That is because we have already been round-and-round
> on it and I have been accused of being repetitious.
> RCM just views the world and its change-patterns
> differently than I do.
>
> RCM does indeed make his designs maintenance-friendly based
> on *his perceptions* of how the world tends to change.
> I don't question him in this regard. He *is* acting
> rationally in that respect (although I wish he
> would state his unspoken assumptions in his works.)
>
> I just have a fundimental disagreement WRT how the
> world tends to change over time. It gets into the
> area of psychology and perception, not so much
> how to code.
The types of changes that can be expected in a particular system are
related to the history of changes in similar systems and the usual
changes due to the technology used to build the systems. This has
nothing to do with psychology.
Robert Martin has considerable experience in a wide variety of systems
and with a wide variety of software. This is documented on his
website and in his articles and books. This experience provides good
reason to trust his estimates of change impact, at least in the
absence of other evidence.
Why should anyone consider your estimates to be equally valid? What
specific systems have you developed that justify anyone considering
your opinion?
Waiting for details,
Sean
Topmind
Test me, smartmouth. Give me a problem sample.
>
>
> Regards,
> Steven Perryman
>
>
>
-T-
Topmind
> You cannot understand the fact that because OO allows multiple
> inheritance, we can build type graphs. If we can build type graphs, then
> by definition we are *not forced to fit things into trees* .
>
> Which kills a big part of your tedious rhetoric stone-dead.
>
ANYthing can be done with MI and a bunch of classes/objects.
I never questioned the possibility. It is the ol'
Turing Equivalency thing.
MI is just *tedious* to use. It is controversial
in the OO community *also* because MI is sticky
to manage for a good many people. I did not create this
controversy, it existed *independently* of me.
Bertrand Meyer talks about the controversy
also in OOSC2 (although he sides with MI).
This is NOT just about me.
For example, if there is a method name
conflict/overlap, OO has no built in way to
handle it. With a p/r approach you can
return multiple matches. OO dispatch
hard-wires in one and only one
dispatching. To get 2 or 0, for example you have
to *overhaul* your fricken code.
I only have to change the dispatching
criteria a little bit instead of overhaul
my code.
Thus, MI risks Meyerian Discontuinity
costs. OO is supposed to make code
change-resistent to new requirements
(according to some OO braggards.)
Well, this is at least one case where
it does not.
(I suppose specific OOP languages could
expend the functionality of MI dispatching,
but it is not an in-born OO feature, and
may not even qualify as OO anymore. It would
be a foot in the database door.)
-T-
Richard Riehle
> A tree is a degenerate case of a graph, with simpler behaviour.
Graph: In-degree of many; out-degree of many
Undirected Graph: No defined direction of the arcs
Directed Graph: Each arc has a defined direction
Tree: Special case of directed graph with an in-degree of
one and
out-degree of one or more
Binary Tree: A tree with an in-degree of one and
an out-degree of two
Any Tree can be represented as a graph. Some graphs can be represented
as trees.
One can represent a tree as a matrix.
This is elementary data structures stuff. Everyone here knows this,
probably
even Topmind, so why are we arguing about it. Check any data structures
book for illustrated examples, pictures and code.
Richard Riehle
Topmind
news:<MPG.188df474f...@news.earthlink.net>...
> > That is because we have already been round-and-round
> > on it and I have been accused of being repetitious.
> > RCM just views the world and its change-patterns
> > differently than I do.
> >
> > RCM does indeed make his designs maintenance-friendly based
> > on *his perceptions* of how the world tends to change.
> > I don't question him in this regard. He *is* acting
> > rationally in that respect (although I wish he
> > would state his unspoken assumptions in his works.)
> >
> > I just have a fundimental disagreement WRT how the
> > world tends to change over time. It gets into the
> > area of psychology and perception, not so much
> > how to code.
>
> The types of changes that can be expected in a particular system are
> related to the history of changes in similar systems and the usual
> changes due to the technology used to build the systems. This has
> nothing to do with psychology.
True, I don't know the exact reasons for our differences.
I assumed it was perception differences (such as remembering
certain patterns and forgetting others), but I should say
that we simply don't know the reasons for our differences.
>
> Robert Martin has considerable experience in a wide variety of systems
> and with a wide variety of software. This is documented on his
> website and in his articles and books. This experience provides good
> reason to trust his estimates of change impact, at least in the
> absence of other evidence.
If he has been in a wide variety of fields, then I doubt his
experience in *custom biz applications* is signficantly
longer than mine, because it has been my *only* domain
(outside of a short stint in geological applications
as an intern.)
I can't fully question his observations
about *other* areas that I
am not familiar with, like device drivers, etc., but
his claims to how *biz* changes over time seem
to contradict my observations.
Further, I spent several paragraphs trying to
explain and justify my reasoning for the patterns
I see. I did *not* see a similar attempt at a
"brain dump" from RCM. RCM has not identified
the "herding agents" that keep changes in
the "shapes" he proposes. IOW, the default
should be "random", not tree nor Mut.Excl. (ME).
ME is *not* random. If the pattern is not
random, then *something* must be herding
it into ME and/or trees.
But, RCM never identified the forces
(human nature, politics, etc.)
that keep changes in the shape
of trees/ME.
"Random until proven otherwise" seems
like a reasonable change presumption to me.
>
> Why should anyone consider your estimates to be equally valid? What
> specific systems have you developed that justify anyone considering
> your opinion?
>
> Waiting for details,
I appear to be the only one giving any.
>
> Sean
>
-T-
Mikito Harakiri
news:3E285A3F...@adaworks.com...
> One can represent a tree as a matrix.
>
> This is elementary data structures stuff.
Every graph can be represented by [squared] adjacency matrix, and/or
[rectangular] incidence matrix, and/or [squared] Laplacian. One can link
properties of the matrices to that of the graphs, for example: multiplicity
of eigenvalue 0 in the Laplassian is equal to number of connected
components. This is not elementary data structures stuff.
I don't see any point, however, investigating what type "hierarchies" are:
for example, are they trees, lattices, or DAGs. Well, there was a PhD thesis
by that guy in Finland about multiple inheritance in C++, but then, here
comes Gosling and renders all his research irrelevant.
Likewise, mixin design method was a novelty ~10 yrs ago, but who is using it
today?
In all that OOP anarchy one feature stays anchored: polymorphism. When I
need to traverse a heterogeneous collection, I use it. Is there much value
in OOP beyond this narrow (but, admitedly, powerful) method?
Also, there is no such thing in databases as "heterogeneous collection". If
database schema designer thinks that he needs one, he is in a serious
trouble. For one thing, how would he query heterogeneous collection?
Universe
> In all that OOP anarchy one feature stays anchored: polymorphism. When I
> need to traverse a heterogeneous collection, I use it. Is there much value
> in OOP beyond this narrow (but, admitedly, powerful) method?
The power of modelling reality and imagination as networks of
collaborating and responsible objects with state, encapsulation,
identity, polymorphism, and so on.
Many of are finding OO to be the most generally powerful modelling
paradigm in existence.
Topmind
One can use an "Attribute" table:
Table: Attributes
------------
AttribID // Optional
TableID // A kind of virtual table name
Attrib
AttribValue
You can query it like a regular table, except that
you will need to have "TableID = X and Attrib = Y" in in your
Where clause.
Your last two paragraphs get at the heart of the
conflict between OO and table fans IMO. Polymorphism
(and much of OO) is based on the "dictonary" structure.
OO is a big collection of dictionaries that point
to other dictionaries. IOW, a Network Database (NDB),
similar to those of the 1960's before relational
caught on.
I agree that NDB's are more "organic" than
RDB's, but they also lack the "table" level
in order to apply higher-level logic. IOW,
tables provide a consistency "chunk" which can
be reasoned about. NDB's highest level
is generally still the dictionary
(associative array), which is too
small to do larger-scale aggregate operations
and logic on IMO.
Maybe if a majority of the app required
heterogenious collections, then a NDB/OO
approach may be more appropropriate.
However, in my experience the majority
of the info can be structured nicely
as tables, and Attribute tables like that
above can fill in the rest.
Also, the math and theory of relational (RDB) is more
sound and mature than NDB (dictionary-based) at
this stage in history.
Given these two observations, RDB's are the
superior technology in most cases thus far.
It all comes down to using tables or dictionaries
as the building blocks.
-T-
Richard Riehle
> Also, there is no such thing in databases as "heterogeneous collection". If
> database schema designer thinks that he needs one, he is in a serious
> trouble. For one thing, how would he query heterogeneous collection?
Well, in fact, there is such a thing. And, it can take advantage of
dynamic polymorphism.
In Ada, we have the capability of storing the tag of a type with
its data in a stream database. This is an object-oriented database
since it stores a reference to the methods with the data.
One of my clients implemented this kind of database for an embedded
systems project and it is really slick. As soon as the data item is
retrieved from the database, any operation can be applied using
standard OOP polymorphism.
The schema for this database is not relational in the strict sense
of the word. However, any item can be accessed, directly, and
with a key when appropriate. The accesssor needs only to know
the key, not the associated methods because of polymorphism.
This is a unique application for this client's business and they do
not share the solution with anyone except their own restricted
set of clients. That is, they have chosen not to go commercial
with this solution since they find it gives them a competitive
advantage in their line of business.
Richard Riehle
Alfredo Novoa
>
> Relational theory was not developed for business modeling.
True, it was designed to be the foundation of the entire data
management discipline.
> It is a
> CONTORTION of early business models,
???
> designed for data storage in a flexible
> manner. Specific goals include no duplication of data and easy ad-hoc
> reporting.
It is a very narrow and incorrect view of modern database theory.
> Object modeling was designed for business modeling,
It was designed for simulation modeling, but object data models were
obsoleted a few years later by The Relational Model invention.
> and, in fact, is used by
> many non-developers for this purpose. NO ONE outside of software developers
> use relational theory.
The Relational Model is only a rather direct adaptation of
mathematical logic to the data management problem, and mathematical
logic was widely used during the last 2500 years.
Regards,
Alfredo
Alfredo Novoa
> > Similar parts of queries can be 'factored' to views.
>
> True, but I have a problem with that sometimes. Sometimes
> the duplication may not be universal, but just app-wide (so far).
> RDBMS views tends to be global.
You can use the security mechanism in order to solve that.
Regards,
Alfredo