Why OOP Fails Domain Modeling
topmind
criticize it thoughtfully.
-----
Although I am a critic of OOP in general, the biggest problem with OOP
so far is domain modeling, or domain abstractions (DA). OOP is perhaps
reasonably good at what some call "computational abstractions" (CA).
Computational abstractions are things that manage artifacts of
"computer space", and include GUI, CRUD-Screen related items (forms,
reports, etc.), sockets, data-sets, and so forth.
While I think procedural has been giving a short rift (often because
of lacking languages and not the paradigm itself), the difference
between procedural versions and OO versions of these for CA are not
really different enough to fuss over much, especially if one uses a
dynamic or type-light approach. If forced to use OOP for CA, for the
most part I'd huff a bit, but would get over it.
Domain abstractions are things like customers, products, shopping
carts, vendors, employees, invoices, inventory, etc. OOP has for the
most part failed this side of modeling so far. It's reasonable success
at CA cannot be recreated on the DA side. Even a fair amount of OOP
fans I often debate agree with me more or less on this fact.
So the next question comes up, why the difference between CA and DA?
Why can't the success carry over?
One possibility is complexity. Are DA's more complex than CA's? In my
experience both CA complexity and DA complexity can range widely. I
couldn't say with any kind of definitiveness that one is inherently
more complex than another.
What about standardization? CA's have a certain amount of uniformity
to them for the most part. Most GUI systems seem to share the same
kinds of features and techniques, for example. They are generally
tried and tested over the decades such that they either solve their
job well or they are familiar enough that the quirks and oddities are
known and familiar, and can thus be dealt with.
The same cannot really be said for DA's because they are more likely
to be custom than CA's. However, this does not seem to be the primary
reason for the difference, or at least one that can be analyzed well
at this point.
But there is one big difference between most CA's and DA's: volume.
Domain abstractions often involve lots of similar parts or
reoccurrences. These are usually called "instances" in OOP.
Because of this volume, the instances are usually stored in relational
databases, or RDBMS. Some OOP proponents feel that RDBMS should be
replaced with object databases (OODBMS), but this is not likely to
happen anytime soon. RDBMS have shown they have staying power and are
not likely to go anywhere for some time. Thus, they are a reality for
domain modeling whether you want them to be or not, for OODBMS have
for the most part flopped.
The problem is that OOP has not figured out how to work smoothly with
RDBMS; it is a fitful marriage as one might find in Hollywood couples.
For one, both practically and philosophically, RDBMS do not focus on
the object level, or even "entity" level. (Entities are a somewhat
close match to objects or classes).
For example, a "parts" table may have 40 columns. However, for a
summary of all parts worth in the warehouse grouped by vendor, only
the Vendor ID and Price would be needed out of these 40 columns.
(Things like vendor name may come from other tables.)
For network communication efficiency, the RDBMS would process and sum
only using these two columns and send the result to the application to
display on a screen or report. The other 38 columns are not in the
picture. The total volume of data is only about 5% of the total
available for the entity.
(And it's even less if we are merely summing by vendor. If the average
vendor has about 7 parts, then there is only one summary record for
every seven parts, and the total data sent over the network may be
less than 1 percent than if all the part objects or records were sent
to the application to do the summing.)
But in OOP you generally don't sub-divide objects. It's not called
"sub-object oriented programming" after all. It's based around whole
objects. However, if they are dealt with as a whole object, then you
have to marshal around all 40 columns or attributes to process them
even if you don't use the entire object at a time. It's like carrying
the entire cartoon of milk to the TV room even though you only want a
mug's worth.
One may have a method called "sum_by_vendor" instead, which talks to
the RDBMS and delivers the sums. However the RDBMS is still doing most
of the work because it would be inefficient to transfer the entire 40
columns to an object processor. The method is merely a function-like
wrapper around a query, so this is not really OOP.
RDBMS are designed to answer "queries". The answers can take
information from the total available data, and the subset used in the
answer has no obligation to reflect the entire "object" or objects. It
provides only the answer (data) requested of it. It's no coincidence
that Oracle named their company after a professional question answerer
from ancient Greece.
Further, "joins" can combine multiple entities and produce a result
that is "blind" to the fact that the original info came from two or
more entities (tables). Framing everything in terms of the unit
"object" is foreign to it.
Now it is possible to translate RDBMS results into "objects" per se,
but it tends to create unnatural artifacts. For example, if a given
task only needs say 6 attributes out of an available 40 columns, it
could be wasteful bandwidth-wise to fill all 40 from the database. So
one trick is to leave the non-used attributes blank. However, we then
have a "dirty" object. We risk accidentally using it for another
purpose that needs one of the attributes we left blank.
Another problem is staleness. Over time the object may grow out of
synch with the database as changes to the database are not passed on
to the object copy in the application's memory. Other users may be
modifying the data at the same time you are; which means you may be
processing old data and not know it.
In procedural programming used with RDBMS, usually one only uses the
query results for the immediate task at hand and then discards it when
done with that task. The RDBMS is assumed the official "keeper of the
state", and not memory objects that are an attempt to model actual
objects from the real world. RDBMS are well-tuned and suited for a get-
only-what-you-need-for-this-task viewpoint. It is a kind of hit-and-
run style of processing. It's the question-and-answer system at work.
This directly conflicts with the OOP philosophy of having little
machines hanging around that reflect real-world nouns (sometimes
called "state machines").
There are tools, known as Object-Relational-Mappers (ORM) that attempt
to automate around these issues so that objects appear to be whole and
updated to the application. However, they are awkward and require a
lot of skill to understand, tune performance for, get database
synching right, and to troubleshoot. It thus results in a paradigm
translation tax, and a big tax at that.
Very few who've worked with ORM's say they are wonderful things
(except maybe those who've invested a career in them and are paid
well). At best they view them as a necessary evil because they really
want to stick to an object view of the world. Some see ORM's as a
temporary hold-over until the day OODBMS replace RDBMS, which will
probably happen after cancer is cured and there is world peace. ORM's
are growing more complex than the application language itself in many
cases. It's a lot of effort to hide from the question-and-answer
oracle.
OOP's success on the computational abstraction (CA) side appears to
have made people over-eager to apply that success to domain
abstractions (DA). It does make some sense from a consistency
standpoint: if you have objects for CA, when why not for DA also in
order to not have to switch mental hats while working with the
application.
It's an understandable goal, but if achieving it makes a messy
application with a bloated and finicky ORM translation layer, then
perhaps its time to question the quest for "object purity". A
technique or paradigm that works well in one place (CA) may not
necessarily work well for another (DA).
It's time to start focusing on the best tool for the job instead of
purity or singularity of view. Some complain that SQL is a messy,
ugly, unnatural language that is hard to work with. OOP is to them a
better match for how developers view the world than SQL.
Part if it is education, I believe. It just takes a while to get the
hang of SQL. It also takes a while to get the hang of ORM's, I should
note. But, there are also things about SQL that could certainly be
improved. I'd even created my own draft relational language that is
meant to work around sore spots I see in SQL. But in the shorter-term,
we are stuck with SQL as the de-facto RDBMS standard (or semi-
standard).
As it is now, embracing semi-ugly SQL appears to be the lesser of the
two evils. ORM don't entirely allow developers to hide from SQL
anyhow. When things go wrong, such as performance problems,
understanding the SQL that the ORM generates is paramount.
Further, understanding SQL better over time offers continuous
improvements. But, learning ORM will still result in a wall because
the translation zone will always be a translation zone that requires
attendance. Every new application will need a translation zone with
its own quirks and oddities specific to that application.
If you do a lot of business in Spain, there comes a point where it's
more economical to learn Spanish rather than keep relying on a
translator companion. Your communication will be eventually faster,
smoother, more convenient, and with fewer awkward moments.
Being object and query bilingual is not a bad thing.
Thanks
-T-
Michael Ekstrand
> Although I am a critic of OOP in general, the biggest problem with OOP
> so far is domain modeling, or domain abstractions (DA). OOP is perhaps
> reasonably good at what some call "computational abstractions" (CA).
> Computational abstractions are things that manage artifacts of
> "computer space", and include GUI, CRUD-Screen related items (forms,
> reports, etc.), sockets, data-sets, and so forth.
>
> While I think procedural has been giving a short rift (often because
> of lacking languages and not the paradigm itself), the difference
> between procedural versions and OO versions of these for CA are not
> really different enough to fuss over much, especially if one uses a
> dynamic or type-light approach. If forced to use OOP for CA, for the
> most part I'd huff a bit, but would get over it.
>
> Domain abstractions are things like customers, products, shopping
> carts, vendors, employees, invoices, inventory, etc. OOP has for the
> most part failed this side of modeling so far. It's reasonable success
> at CA cannot be recreated on the DA side. Even a fair amount of OOP
> fans I often debate agree with me more or less on this fact.
>
> So the next question comes up, why the difference between CA and DA?
> Why can't the success carry over?
In general, after a brief skim, your essay looks decently on-target
provided that its scope is sufficiently limited. And therein lies the
problem -- the scope isn't limited.
Sure, there are DA's for which the OO model doesn't work very well, and
I think you do a decent job of exemplifying them and laying out a case
for how it doesn't work.
There are, however, DA's for which it seems to work much better. The
immediate family of ones that come to mind are those for which Simula
was originally written -- simulations. If all your objects are doing is
storing information and performing simple operations, sure, the RDBMS
may very well be a better facility. But if you're creating an
environment of different objects with complex interactions and
inter-relations, I think that OO, properly applied, can be a big win.
It can also be a win when the domain model suggests a collection of
similar but distinct types of items. Modelling this (for example, an
inventory where some items are Books, some are CD's, and some Generic
Items) can be rather obtuse in an RDBMS, while it is very natural with
subtyping and inheritance-based polymorphism (until you do something
that needs multiple dispatch and you're in Java, C++, or whatever).
So, I think you've got something of a point, and I certainly think that
OO is rather abused in present programming practice (although seemingly
for vastly different reasons than you), but I do think it does have
merit for some domains.
- Michael
--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.
H. S. Lahman
I love it! It is so YOU! This is one of your better chain-pulling efforts.
You open with the absurd premise that OO is only good for modeling the
computing space.
Then you justify that premise by citing OOP's problems with mapping to a
DBMS. The irony is marvelous!
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Phlip
> Although I am a critic of OOP in general, the biggest problem with OOP
> so far is domain modeling, or domain abstractions (DA). OOP is perhaps
> reasonably good at what some call "computational abstractions" (CA).
> Computational abstractions are things that manage artifacts of
> "computer space", and include GUI, CRUD-Screen related items (forms,
> reports, etc.), sockets, data-sets, and so forth.
So, in your heroic quest to learn enough about OO to debunk it, you have
discovered that Big Design Up Front is Bad, and that OO itself is innocent!
"Break on thru to the other side!" --the Doors [of Perception]
> While I think procedural has been giving a short rift (often because
"short shrift"? (-:
--
Phlip
topmind
Perhaps. In simulations you may have hundreds of items, not millions,
such that the database issue is not hanging over one's shoulder.
>
> It can also be a win when the domain model suggests a collection of
> similar but distinct types of items. Modelling this (for example, an
> inventory where some items are Books, some are CD's, and some Generic
> Items) can be rather obtuse in an RDBMS, while it is very natural with
> subtyping and inheritance-based polymorphism (until you do something
> that needs multiple dispatch and you're in Java, C++, or whatever).
We've had a big debate about this very kind of library media example
about a year ago. I didn't see any big advantage of OOP here. Each
approach had various trade-offs and none stood out. For one, I felt a
set-based taxonomy was more flexible than a hierarchy-based one.
>
> So, I think you've got something of a point, and I certainly think that
> OO is rather abused in present programming practice (although seemingly
> for vastly different reasons than you), but I do think it does have
> merit for some domains.
So we can agree that "OO everywhere" should be replaced with "use OO
only where it helps."
>
> - Michael
>
> --
Thanks for your feedback.
-T-
topmind
> topmind writes:
> > Although I am a critic of OOP in general, the biggest problem with OOP
> > so far is domain modeling, or domain abstractions (DA). OOP is perhaps
> > reasonably good at what some call "computational abstractions" (CA).
> > Computational abstractions are things that manage artifacts of
> > "computer space", and include GUI, CRUD-Screen related items (forms,
> > reports, etc.), sockets, data-sets, and so forth.
>
> So, in your heroic quest to learn enough about OO to debunk it, you have
> discovered that Big Design Up Front is Bad, and that OO itself is innocent!
>
Sorry, I don't see the connection between the two.
> "Break on thru to the other side!" --the Doors [of Perception]
>
> > While I think procedural has been giving a short rift (often because
>
> "short shrift"? (-:
>
> --
> Phlip
-T-
S Perryman
> Responding to Jacobs...
> I love it! It is so YOU! This is one of your better chain-pulling efforts.
> You open with the absurd premise that OO is only good for modeling the
> computing space.
> Then you justify that premise by citing OOP's problems with mapping to a
> DBMS. The irony is marvelous!
You are very disrespectful.
He has obviously been beavering away for a long time on this (and sparing
comp.object his continual 'sewage spills' in the process) .
Sadly, if it takes this long to write something that is but a std press
release from the Ministry of the Bleeding Obvious, how many of us will live
to see him post something useful ...
Regards,
Steven Perryman
S Perryman
news:922fce20-1853-402e...@r35g2000prm.googlegroups.com...
> Domain abstractions are things like customers, products, shopping
> carts, vendors, employees, invoices, inventory, etc. OOP has for the
> most part failed this side of modeling so far. It's reasonable success
> at CA cannot be recreated on the DA side. Even a fair amount of OOP
> fans I often debate agree with me more or less on this fact.
Domain abstractions are things like :
subscriber, mobile phone, optical fibre, multiplexer, base station, switch,
communications connection, router, line card etc.
OOP has for the most part succeeded this side of modelling so far.
Its reasonable success at CA has been recreated on the DA side.
Even a fair amount of OOP detractors I often debate with agree with me or
less on this fact.
> So the next question comes up, why the difference between CA and DA?
> Why can't the success carry over?
So the next question comes up :
Why is there no real difference between CA and DA for OO ??
Why does the success carry over ??
> One possibility is complexity.
One possibility is they use the same underlying concept for both CA and DA.
> Are DA's more complex than CA's? In my
> experience both CA complexity and DA complexity can range widely. I
> couldn't say with any kind of definitiveness that one is inherently
> more complex than another.
Are DAs more complex than CAs for OO ??
In my experience both DA and CA complexity can range widely, but one
can say with some definitiveness that in OO the CA is more complex than
the DA.
> What about standardization? CA's have a certain amount of uniformity
> to them for the most part.
What about standardisation ??
CAs have no degree of uniformity to them for the most part.
A CA based on OO can be fundamentally different to a CA based on
Functional Programming. Which itself can be fundamentally different to a
CA based on the Procedural paradigm.
> Most GUI systems seem to share the same
> kinds of features and techniques, for example.
Most GUI systems seem to face the same kinds of issues, for example.
Which result in the same kinds of solutions.
> They are generally
> tried and tested over the decades such that they either solve their
> job well or they are familiar enough that the quirks and oddities are
> known and familiar, and can thus be dealt with.
> The same cannot really be said for DA's because they are more likely
> to be custom than CA's.
The same can be said for DAs because the concepts have been stabilised,
and realised in tried and tested systems over the decades.
And so on (if I could be arsed - but the reader with assumed nominal
intelligence gets the point) ...
Regards,
Steven Perryman
topmind
S Perryman wrote:
> "topmind" <top...@technologist.com> wrote in message
> news:922fce20-1853-402e...@r35g2000prm.googlegroups.com...
>
> > Domain abstractions are things like customers, products, shopping
> > carts, vendors, employees, invoices, inventory, etc. OOP has for the
> > most part failed this side of modeling so far. It's reasonable success
> > at CA cannot be recreated on the DA side. Even a fair amount of OOP
> > fans I often debate agree with me more or less on this fact.
>
> Domain abstractions are things like :
>
> subscriber, mobile phone, optical fibre, multiplexer, base station, switch,
> communications connection, router, line card etc.
>
> OOP has for the most part succeeded this side of modelling so far.
> Its reasonable success at CA has been recreated on the DA side.
> Even a fair amount of OOP detractors I often debate with agree with me or
> less on this fact.
That's because you guys couldn't figure out how to use a RDBMS right
for your telecom niche, so you instead rolled your own half-ass custom
OODBMS with with lovely pointer-hopping-hell.
OOP has failed to codify or standardize large-volume attribute
management and collection handling in a multi-user networked
environment. Thus, one ends up reinventing it the hard, inconsistent,
sloggy way if they go away from the DB.
>
>
> > They are generally
> > tried and tested over the decades such that they either solve their
> > job well or they are familiar enough that the quirks and oddities are
> > known and familiar, and can thus be dealt with.
>
> > The same cannot really be said for DA's because they are more likely
> > to be custom than CA's.
>
> The same can be said for DAs because the concepts have been stabilised,
> and realised in tried and tested systems over the decades.
There ain't no Dr. Codd of OOP......yet.
>
>
> And so on (if I could be arsed - but the reader with assumed nominal
> intelligence gets the point) ...
Insults do not truth make.
>
>
> Regards,
> Steven Perryman
-T-
topmind
Like you are so full of evidence. Full of something, but not evidence.
>
> Regards,
> Steven Perryman
-t-
Lee Riemenschneider
wrote:
> It's time to start focusing on the best tool for the job instead of
> purity or singularity of view. Some complain that SQL is a messy,
> ugly, unnatural language that is hard to work with. OOP is to them a
> better match for how developers view the world than SQL.
>
should at least advocate something more truly relational than SQL.
I'll defer any comments to the writings of Fabian Pascal, C.J.Date,
and Hugh Darwen on the subject.
Lahman should have given you a pass on this one, since he'd probably
agree that the state of the art in OOPL does a very poor job of
properly defining domains. At least you limited it to OOP and not
encompassing all of OT.
--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com
S Perryman
> S Perryman wrote:
>> "topmind" <top...@technologist.com> wrote in message
>> news:922fce20-1853-402e...@r35g2000prm.googlegroups.com...
>>> Domain abstractions are things like customers, products, shopping
>>> carts, vendors, employees, invoices, inventory, etc. OOP has for the
>>> most part failed this side of modeling so far. It's reasonable success
>>> at CA cannot be recreated on the DA side. Even a fair amount of OOP
>>> fans I often debate agree with me more or less on this fact.
>> Domain abstractions are things like :
>> subscriber, mobile phone, optical fibre, multiplexer, base station,
>> switch,
>> communications connection, router, line card etc.
>> OOP has for the most part succeeded this side of modelling so far.
>> Its reasonable success at CA has been recreated on the DA side.
>> Even a fair amount of OOP detractors I often debate with agree with me or
>> less on this fact.
> That's because you guys couldn't figure out how to use a RDBMS right
> for your telecom niche, so you instead rolled your own half-ass custom
> OODBMS with with lovely pointer-hopping-hell.
1. Completely unrelated to what I have written above (which kills your
claims
about OO and "DA" ) .
2. The RDBMS "guys" couldn't use their beloved systems to incorporate
both polymorphic info storage and behaviour access, together with their
only
procedural hammer (the "variant" record) , to provide the system
performance and
code flexibility that the telecoms domains required.
Or to paraphrase you :
They instead rolled their own half-arsed custom meta-typing, type
substitutability
systems with lovely masses of "case statements" + "type ids stored in the
RDBMS"
hell.
Regards,
Steven Perryman
topmind
> "topmind" <topm...@technologist.com> wrote in message
>
> news:eb83cca3-de4a-488c...@n38g2000prl.googlegroups.com...
>
>
>
> > S Perryman wrote:
> >>news:922fce20-1853-402e...@r35g2000prm.googlegroups.com...
> >>> Domain abstractions are things like customers, products, shopping
> >>> carts, vendors, employees, invoices, inventory, etc. OOP has for the
> >>> most part failed this side of modeling so far. It's reasonable success
> >>> at CA cannot be recreated on the DA side. Even a fair amount of OOP
> >>> fans I often debate agree with me more or less on this fact.
> >> Domain abstractions are things like :
> >> subscriber, mobile phone, optical fibre, multiplexer, base station,
> >> switch,
> >> communications connection, router, line card etc.
> >> OOP has for the most part succeeded this side of modelling so far.
> >> Its reasonable success at CA has been recreated on the DA side.
> >> Even a fair amount of OOP detractors I often debate with agree with me or
> >> less on this fact.
> > That's because you guys couldn't figure out how to use a RDBMS right
> > for your telecom niche, so you instead rolled your own half-ass custom
> > OODBMS with with lovely pointer-hopping-hell.
>
> 1. Completely unrelated to what I have written above (which kills your
> claims
> about OO and "DA" ) .
Improve your writing.
>
> 2. The RDBMS "guys" couldn't use their beloved systems to incorporate
> both polymorphic info storage and behaviour access, together with their
> only
> procedural hammer (the "variant" record) , to provide the system
> performance and
> code flexibility that the telecoms domains required.
Based on your library media example a year or so ago, I can see why
you'd tie yourself in a knot. Your static RAMmy thinking gets you
stuck.
>
> Or to paraphrase you :
>
> They instead rolled their own half-arsed custom meta-typing, type
> substitutability
> systems with lovely masses of "case statements" + "type ids stored in the
> RDBMS"
> hell.
That's what you said about the library example, and I proved you flat
wrong and enjoyed proving you flat wrong because you are stubborn and
narrow-minded. You are a poor designer and I wouldn't want to touch
your crap with an 80-foot telephone pole.
Do we need to review the library example again, or have you had enough
wippin's?
Variant Shmariant.
>
> Regards,
> Steven Perryman
-T-
topmind
wrote:
> On Sat, 23 Aug 2008 04:42:31 UTC, topmind <topm...@technologist.com>
> wrote:> It's time to start focusing on the best tool for the job instead of
> > purity or singularity of view. Some complain that SQL is a messy,
> > ugly, unnatural language that is hard to work with. OOP is to them a
> > better match for how developers view the world than SQL.
>
> If you're going to go this far in the name of relational, then you
> should at least advocate something more truly relational than SQL.
> I'll defer any comments to the writings of Fabian Pascal, C.J.Date,
> and Hugh Darwen on the subject.
I was trying to stay somewhat grounded in reality and focus on what
RDBMS offer in the shorter term. If/when better RDBMS and/or query
languages come out, then there will be even more options for domain
modeling.
>
> Lahman should have given you a pass on this one, since he'd probably
> agree that the state of the art in OOPL does a very poor job of
> properly defining domains. At least you limited it to OOP and not
> encompassing all of OT.
>
> --
> Lee W. Riemenschneider
> GO BOILERS!
> Running eComStation (eCS)(the latest incarnation of OS/2)
> Buy eCS everyone! Buy it now! http://www.ecomstation.com
-T-
S Perryman
> On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
SP> OOP has for the most part succeeded this side of modelling so far.
SP> Its reasonable success at CA has been recreated on the DA side.
SP> Even a fair amount of OOP detractors I often debate with agree with me
or
SP> less on this fact.
TM> That's because you guys couldn't figure out how to use a RDBMS right
TM> for your telecom niche, so you instead rolled your own half-ass custom
TM> OODBMS with with lovely pointer-hopping-hell.
>> 1. Completely unrelated to what I have written above (which kills your
>> claims about OO and "DA" ) .
> Improve your writing.
Still haven't got that basic command of English yet, have you.
Your rubbish about "rolled" etc has absolutely nothing to do with the
comment that OO is as successful on the "DA" side as the "CA" side.
>> 2. The RDBMS "guys" couldn't use their beloved systems to incorporate
>> both polymorphic info storage and behaviour access, together with
>> their
>> only procedural hammer (the "variant" record) , to provide the system
>> performance and code flexibility that the telecoms domains required.
> Based on your library media example a year or so ago, I can see why
> you'd tie yourself in a knot. Your static RAMmy thinking gets you
> stuck.
I'm describing your solution, not mine. How very silly of you (again) .
>> Or to paraphrase you :
>> They instead rolled their own half-arsed custom meta-typing, type
>> substitutability
>> systems with lovely masses of "case statements" + "type ids stored in the
>> RDBMS" hell.
> That's what you said about the library example, and I proved you flat
> wrong and enjoyed proving you flat wrong because you are stubborn and
> narrow-minded. You are a poor designer and I wouldn't want to touch
> your crap with an 80-foot telephone pole.
> Do we need to review the library example again, or have you had enough
> wippin's?
1. No need. Your embarrassingly amusing prevarications are on record :
http://groups.google.com/group/comp.databases.theory/msg/f92b9751ef677e0d
2. Goto "real-world systems" .
Which, given the Library example was a very stripped down version of
something
that has been done for years in telecom nw management systems using OOP (ie
systems that control various kinds of *real equipment* that have different
hw/protocol implementations for properties possessed by *different and/or
same*
types of entity) ...
What was your solution again ??
Oh thats' right. Your half-baked incomplete solution assumes that :
- all the properties of every entity was pure data, and not behaviour
- and that the data representation for any property common to more than
one entity was the same for all entity types
So you could not even provide a "P/R" solution for a real-world problem
stripped down to the level that a little kid can understand it.
But anyway, I can see why you want to thrash around elsewhere (as always) .
Your claims about OOP failing domain modelling have been shown to be
your usual ignorant un-researched rubbish.
Regards,
Steven Perryman
topmind
S Perryman wrote:
> "topmind" <top...@technologist.com> wrote in message
> news:d77e145a-bacd-429a...@o40g2000prn.googlegroups.com...
>
> > On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
>
> SP> OOP has for the most part succeeded this side of modelling so far.
> SP> Its reasonable success at CA has been recreated on the DA side.
> SP> Even a fair amount of OOP detractors I often debate with agree with me
> or
> SP> less on this fact.
>
> TM> That's because you guys couldn't figure out how to use a RDBMS right
> TM> for your telecom niche, so you instead rolled your own half-ass custom
> TM> OODBMS with with lovely pointer-hopping-hell.
>
> >> 1. Completely unrelated to what I have written above (which kills your
> >> claims about OO and "DA" ) .
>
> > Improve your writing.
>
> Still haven't got that basic command of English yet, have you.
Projecting.
> >> Or to paraphrase you :
>
> >> They instead rolled their own half-arsed custom meta-typing, type
> >> substitutability
> >> systems with lovely masses of "case statements" + "type ids stored in the
> >> RDBMS" hell.
>
> > That's what you said about the library example, and I proved you flat
> > wrong and enjoyed proving you flat wrong because you are stubborn and
> > narrow-minded. You are a poor designer and I wouldn't want to touch
> > your crap with an 80-foot telephone pole.
>
> > Do we need to review the library example again, or have you had enough
> > wippin's?
>
> 1. No need. Your embarrassingly amusing prevarications are on record :
>
> http://groups.google.com/group/comp.databases.theory/msg/f92b9751ef677e0d
>
You claimed there would be a "combinatorial explosion" and there
WASN'T any. You tried to later stretch the definition of C.E. to force
one to "exist" using null-play word games. You got pounded there. Live
with your mental wound; you were shown up. Accept it like man.
>
> 2. Goto "real-world systems" .
>
> Which, given the Library example was a very stripped down version of
> something
> that has been done for years in telecom nw management systems using OOP (ie
> systems that control various kinds of *real equipment* that have different
> hw/protocol implementations for properties possessed by *different and/or
> same*
> types of entity) ...
>
> What was your solution again ??
> Oh thats' right. Your half-baked incomplete solution assumes that :
>
> - all the properties of every entity was pure data, and not behaviour
And that's a bad thing? Tons of repetitious set/gets is mindless code-
bloating repetition that cranks up development cost and makes
programmers drool out of boredom and get carpel tunnel.
>
> - and that the data representation for any property common to more than
> one entity was the same for all entity types
Why is this a bad thing? If you want a different one, you make a
different one. It also depends how its implemented: I showed 2
different approaches one could take to boost different factors
depending on customer patterns of change.
>
> So you could not even provide a "P/R" solution for a real-world problem
> stripped down to the level that a little kid can understand it.
>
It was better then yours.
>
> But anyway, I can see why you want to thrash around elsewhere (as always) .
> Your claims about OOP failing domain modelling have been shown to be
> your usual ignorant un-researched rubbish.
Projecting. You make bloated verbose crap for job security.
>
>
> Regards,
> Steven Perryman
-T-
S Perryman
> S Perryman wrote:
>> "topmind" <top...@technologist.com> wrote in message
>> news:d77e145a-bacd-429a...@o40g2000prn.googlegroups.com...
>>
>> > On Aug 25, 11:23 pm, "S Perryman" <a...@a.net> wrote:
>>
>> SP> OOP has for the most part succeeded this side of modelling so far.
>> SP> Its reasonable success at CA has been recreated on the DA side.
>> SP> Even a fair amount of OOP detractors I often debate with agree with
>> me
>> or
>> SP> less on this fact.
>>
>> TM> That's because you guys couldn't figure out how to use a RDBMS right
>> TM> for your telecom niche, so you instead rolled your own half-ass
>> custom
>> TM> OODBMS with with lovely pointer-hopping-hell.
>>
SP> 1. Completely unrelated to what I have written above (which kills your
SP> claims about OO and "DA" ) .
TM> Improve your writing.
>> Still haven't got that basic command of English yet, have you.
> Projecting.
Your usual careful snipping of the relevant text (as always) .
I'll put back anyway, as it marks your original thread topic as dead.
<quote+1>
Your rubbish about "rolled" etc has absolutely nothing to do with the
comment that OO is as successful on the "DA" side as the "CA" side.
</quote>
Now we can return to your usual diversionary tactics ...
SP> They instead rolled their own half-arsed custom meta-typing, type
SP> substitutability
SP> systems with lovely masses of "case statements" + "type ids stored in
the
SP> RDBMS" hell.
TM> That's what you said about the library example, and I proved you flat
TM> wrong and enjoyed proving you flat wrong because you are stubborn and
TM> narrow-minded. You are a poor designer and I wouldn't want to touch
TM> your crap with an 80-foot telephone pole.
TM> Do we need to review the library example again, or have you had enough
TM> wippin's?
>> 1. No need. Your embarrassingly amusing prevarications are on record :
>> http://groups.google.com/group/comp.databases.theory/msg/f92b9751ef677e0d
> You claimed there would be a "combinatorial explosion" and there
> WASN'T any. You tried to later stretch the definition of C.E. to force
> one to "exist" using null-play word games. You got pounded there. Live
> with your mental wound; you were shown up. Accept it like man.
Tis all there for people to see.
1. The stripped down example had 5 entity types, about 10 property types,
3 of which were shared.
So a '10 x 5' problem.
And for the *real-world* problem. 100+ different entity types, 100+
different properties.
1. So a '100+ x 100+' = *10000+* problem.
Hmm, for a small change in the entity and property sets (5 to 100+ , 10 to
100+ ) ,
a two orders of magnitude increase in the permutation space.
The maths domain has a description for such occurrences ...
2. What does your (not actually a complete equivalent of my OO) "solution"
look like for the *real-world* problem ??
One that had millions of instances of the various entity types.
>> 2. Goto "real-world systems" .
>> Which, given the Library example was a very stripped down version of
>> something
>> that has been done for years in telecom nw management systems using OOP
>> (ie
>> systems that control various kinds of *real equipment* that have
>> different
>> hw/protocol implementations for properties possessed by *different and/or
>> same* types of entity) ...
>> What was your solution again ??
>> Oh thats' right. Your half-baked incomplete solution assumes that :
>> - all the properties of every entity was pure data, and not behaviour
> And that's a bad thing? Tons of repetitious set/gets is mindless code-
> bloating repetition that cranks up development cost and makes
> programmers drool out of boredom and get carpel tunnel.
#1
>> - and that the data representation for any property common to more than
>> one entity was the same for all entity types
> Why is this a bad thing?
#2
> If you want a different one, you make a
> different one. It also depends how its implemented: I showed 2
> different approaches one could take to boost different factors
> depending on customer patterns of change.
#1 / #2.
Not a bad thing at all in general.
But in the real world, some of the entities/properties are in different
databases (legacy) . Some of the entities/properties in fact are
computational
behaviours that exist on different systems (telecoms equipment etc) .
All these factors affecting the optimal solution.
And the extent of change needed to accommodate these factors.
Does this resemble a real world you have worked in ?? One where :
- instances of the same entity type have different implementation behaviours
based on where in the system they reside ??
- the data representations of entities are not held in the same data
repository,
different repository impls (SQL, OODB etc) ??
>> So you could not even provide a "P/R" solution for a real-world problem
>> stripped down to the level that a little kid can understand it.
> It was better then yours.
Who knows ??
You can't even tell anyone what your "solution" outputs for the given test
inputs. Even when you have been shown what the expected outputs are.
From what I can deduce, it does something completely different.
But as I said, twas a problem that a little kid can understand ...
Regards,
Steven Perryman
topmind
> "topmind" <topm...@technologist.com> wrote in message
>
> news:a3b1e334-c15c-441a...@b2g2000prf.googlegroups.com...
>
>
>
> > S Perryman wrote:
> > You claimed there would be a "combinatorial explosion" and there
> > WASN'T any. You tried to later stretch the definition of C.E. to force
> > one to "exist" using null-play word games. You got pounded there. Live
> > with your mental wound; you were shown up. Accept it like man.
>
> Tis all there for people to see.
>
> 1. The stripped down example had 5 entity types, about 10 property types,
> 3 of which were shared.
>
> So a '10 x 5' problem.
>
> And for the *real-world* problem. 100+ different entity types, 100+
> different properties.
>
> 1. So a '100+ x 100+' = *10000+* problem.
> Hmm, for a small change in the entity and property sets (5 to 100+ , 10 to
> 100+ ) ,
> a two orders of magnitude increase in the permutation space.
>
> The maths domain has a description for such occurrences ...
You forgot already? That's how YOU would do it because you are bad at
procedural/relational programming. That's not how I did it.
There is no need to replicate shared attributes.
Without looking at something more specific, it is hard to evaluate
your claims. Your "problems" are often artifacts of your OWN bad
designs.
>
> - the data representations of entities are not held in the same data
> repository,
> different repository impls (SQL, OODB etc) ??
>
> >> So you could not even provide a "P/R" solution for a real-world problem
> >> stripped down to the level that a little kid can understand it.
> > It was better then yours.
>
> Who knows ??
> You can't even tell anyone what your "solution" outputs for the given test
> inputs. Even when you have been shown what the expected outputs are.
> From what I can deduce, it does something completely different.
What are you talking about?
>
> But as I said, twas a problem that a little kid can understand ...
>
> Regards,
> Steven Perryman
-T-
S Perryman
> On Sep 1, 4:37 am, "S Perryman" <a...@a.net> wrote:
TM> Do we need to review the library example again, or have you had enough
TM> wippin's?
SP>1. No need. Your embarrassingly amusing prevarications are on record :
SP>http://groups.google.com/group/comp.databases.theory/msg/f92b9751ef67...
SP> You claimed there would be a "combinatorial explosion" and there
SP> WASN'T any. You tried to later stretch the definition of C.E. to force
SP> one to "exist" using null-play word games. You got pounded there. Live
SP> with your mental wound; you were shown up. Accept it like man.
>> Tis all there for people to see.
>> 1. The stripped down example had 5 entity types, about 10 property types,
>> 3 of which were shared.
>> So a '10 x 5' problem.
>> And for the *real-world* problem. 100+ different entity types, 100+
>> different properties.
>> 1. So a '100+ x 100+' = *10000+* problem.
>> Hmm, for a small change in the entity and property sets (5 to 100+ , 10
>> to
>> 100+ ) , a two orders of magnitude increase in the permutation space.
>> The maths domain has a description for such occurrences ...
> You forgot already? That's how YOU would do it because you are bad at
> procedural/relational programming. That's not how I did it.
> There is no need to replicate shared attributes.
What rubbish are you writing now !!??
If I have 100+ attr types, what is your "solution" going to be ??
Attributes(EntityInstanceId,Attr1,Attr2, ... Attr100, ... ) ??
Because that is what your "solution" is for the toy-town example.
>> 2. What does your (not actually a complete equivalent of my OO)
>> "solution"
>> look like for the *real-world* problem ??
>> One that had millions of instances of the various entity types.
[ snip ... ]
>> But in the real world, some of the entities/properties are in different
>> databases (legacy) . Some of the entities/properties in fact are
>> computational behaviours that exist on different systems (telecoms
>> equipment etc) .
>> All these factors affecting the optimal solution.
>> And the extent of change needed to accommodate these factors.
>> Does this resemble a real world you have worked in ?? One where :
>> - instances of the same entity type have different implementation
>> behaviours
>> based on where in the system they reside ??
> Without looking at something more specific, it is hard to evaluate
> your claims. Your "problems" are often artifacts of your OWN bad
> designs.
All you have to do is something like the following :
SELECT entity
FROM E
WHERE entity.p1 = X
SET p2 = Y ;
With the unfortunate problem that :
- E may be a set of different databases with different underlying impls
- some of the instances of E may be on physically separate systems
- p1 and p2 may not be data values, but implementation behaviour that does
things with *real equipment*
>> You can't even tell anyone what your "solution" outputs for the given
>> test
>> inputs. Even when you have been shown what the expected outputs are.
>> From what I can deduce, it does something completely different.
> What are you talking about?
As I said (sigh) , twas a problem that a little kid can understand.
Can we spell it out even simpler than that for you ?? We'll try ...
If someone gives me a problem to write s/w to add two numbers, and
when they give me the following inputs :
1,1
2,3
they tell me that they expect to see the following outputs :
2
5
then if I produce something that doesn't appear to add two numbers,
and when asked what my program *does actually produce as output* ,
start ranting that "I don't have to write an add program how you tell me
to" etc, I can rightly expect to be treated as an incompetent fool.
Now, read the original thread again ... and go figure !!!
Regards,
Steven Perryman
topmind
> "topmind" <topm...@technologist.com> wrote in message
First, how is that a "combinatorial explosion"?
Second, I offered 2 solutions. The above was only one of them. If the
quantity of attributes changes often, then the 2nd solution would
probably be better.
(I'll reply to other issues later)
-T-
> Regards,
> Steven Perryman
Alvin Ryder
The are many reasons object models are inferior.
Most OO languages can only support memory based models so that alone
instantly disqualifies them from many domains. They do not support
concurrent or secure user access either.
Object models tend to be closed, encasing an internal mesh of
entangled relationships. To change the model, you change the code.
This can be trivial or outrageously expensive.
In my current job they had created a large object model and used a
database merely as a "persistence mechanism". I would have advocated a
multi-paradigm and relational friendly approach but I was too late. At
any rate, now we must add a new feature which requires major new model
elements to be grafted into the model. Since they had one big model
and nearly a million lines of code a significant percentage of code
will now be impacted by this change. OUCH!
If they had smaller models and just passed minimal models around, they
would have been in a better position now.
Anyway, how would the relational model fair?
Obviously most RDBMS can handle the point about memory, concurrency
and security but better still the relational model is open. Relative
to OO it's inside out. You can add as many new relations as you need
and not affect any of the existing ones.
Consider a simple domain: Customer, Stock, Sales.
And now we need to add Suppliers, all we need do is add a
StockSupplier table (for many to one) and Supplier, none of the
existing tables are changed whatsoever.
But in object models you'd invariably need to edit the existing
hierarchy and perform tree surgery, in this case the Stock class would
probably need to have a new list of Suppliers.
This is a simplistic example but hopefully it serves to illustrate how
in the relational model you just add new relations without affecting
anything but in the object model you usually have to edit code.
Granted you can extend by inheritance without damage but that
mechanism is not always the most appropriate choice.
Another big difference is object models are merely *one* possible
snapshot of possible inter-relationships between objects. Whereas the
relational model merely defines the base ingredients (tables) and
tools to combine the ingredients (selections, joins and
projections...) you can formulate *any number of inter-relationships*,
whatever data view you require at any given time. Different
applications or parts of the same app may compose whatever they
desire.
Worse still for the object model, the *one* possible snapshot is
etched in "3G" code rather than a DDL - much more expensive to modify.
No wonder RDBMs have a place in this world, you simply cannot do what
they do with popular OO languages. So we OOP fans reluctantly concede
that point but then try to impose OO at the ORM layer - again another
great blunder. Why can't we just back off? Ignorance, pride,
stupidity?
Topmind I agree with most of your post except the point about the
"object-relational-mapping" marriage needing to be nasty. To be frank,
the ORMs I build are pretty nice to both the relational and object
camps. It just takes some mutual respect on both sides of the fence.
Granted things can turn sour real quick but if you don't let OOP
dominate especially where it is weak things do go better.
Even popular tools like Hibernate and EJB3 abuse databases. As a
result there are unnecessary performance hits, bottlenecks and other
issues. To get the most out of databases like Oracle or SQL Server you
need to give them their due respect, forget about OO for a bit. Do
what the database needs.
I'm a fan of multi-paradigm approaches, at least I try to keep
everyone happy. Prior to this gig I was doing game programming, I
loved it because there were so *many* paradigms, it wasn't just OOP
versus Relational. There's the game engine, rendering libraries
(opengl..), sound libraries, math, physics, networking,
animation, ... funny enough many of these do not use OO and they have
an obvious C heritage. Granted some have shifted to C++ but not in an
overly OO way. If you focus on OOP instead of the job at hand - you
are simply DOOMED.
Cheers
BTW. in game programming artists might use tools like 3D Studio Max
and Maya to create worlds and characters, these are then exported as a
mesh which is usually just a stream of data ... then to cut a long
story short the game engine renders that data and you see a magical 3D
world. How can this be an object model? One team of applications
creates the models and another renders it? You cannot export the code
guts from studio max. The data just has to be data.
Leslie Sanford
"Alvin Ryder" wrote:
<snip>
> Consider a simple domain: Customer, Stock, Sales.
>
> And now we need to add Suppliers, all we need do is add a
> StockSupplier table (for many to one) and Supplier, none of the
> existing tables are changed whatsoever.
>
> But in object models you'd invariably need to edit the existing
> hierarchy and perform tree surgery, in this case the Stock class would
> probably need to have a new list of Suppliers.
>
> This is a simplistic example but hopefully it serves to illustrate how
> in the relational model you just add new relations without affecting
> anything but in the object model you usually have to edit code.
> Granted you can extend by inheritance without damage but that
> mechanism is not always the most appropriate choice.
When I see these sorts of examples, my question is always where does the
behavior go?
My area of programming is DSP. I deal with software models of things like
oscillators and filters. If I want, I can create a table to represent the
properties of these models. For example:
Filter Table:
ID | Cutoff Frequency | Resonance | Type
0 10000 0.5 Lowpass
1 5000 0.75 Bandpass
Great. But I need an engine to make the filter run; I need to feed a filter
an input stream which it filters and use the results. That has to go
somewhere. Instead of using tables, I use objects. The fields of a table
become the properties of the object. And as far as running the filter, all I
have to do is something like:
outputStream = filter.Process(inputStream);
So... I dunno. I've never been able to wrap my head around how a relational
model can help me realize a realtime DSP system.
Alvin Ryder
wrote:
Hi Leslie,
Good example but I don't know enough about real-time DSP systems to
even offer a suggestion. In theory the relational model can still be
used to represent your data but then you'll need a RDBMS suitable for
running in a realtime DSP environment, so I dare say we might be out
of luck there ;-)
I've worked with many game engines (although now I'm doing graphics/
java stuff) so I was in a similar boat as you in the sense that no
RDBMS could be found that co-works with game engines. But this doesn't
stop us from at least borrowing some relational ideas.
Rather than one complex model I tend to gravitate towards simpler,
application neutral, pretty dumb "atom" type objects, then I compose
application specific "molecules" by combining "atoms". At any given
time I pass around as small and dumb a sub-model as possible.
Conversely if we have one big model then changing the model directly
affects or at least threatens to affect a lot of other code.
Anyway I was just trying to provide food for thought and advocate a
friendly multi-paradigm approach. I don't see the need to have the
object and relational models so violently opposed to each other ;-)
Cheers.
S Perryman
news:5a024bf5-6329-424d...@b2g2000prf.googlegroups.com...
> Anyway I was just trying to provide food for thought and advocate a
> friendly multi-paradigm approach. I don't see the need to have the
> object and relational models so violently opposed to each other ;-)
In theory, they do not oppose eachother.
In reality, they do.
Primarily due to the "mismatch impedence" problem caused by the
implementations of the prevailing RDBMS (SQL etc) , and OO prog langs
(C++ etc) .
Regards,
Steven Perryman
Leslie Sanford
> "Leslie Sanford" wrote:
<snip>
>> So... I dunno. I've never been able to wrap my head around how a
>> relational model can help me realize a realtime DSP system.
>
> Hi Leslie,
>
> Good example but I don't know enough about real-time DSP systems to
> even offer a suggestion. In theory the relational model can still be
> used to represent your data but then you'll need a RDBMS suitable for
> running in a realtime DSP environment, so I dare say we might be out
> of luck there ;-)
>
> I've worked with many game engines (although now I'm doing graphics/
> java stuff) so I was in a similar boat as you in the sense that no
> RDBMS could be found that co-works with game engines. But this doesn't
> stop us from at least borrowing some relational ideas.
I have to admit to not being very experienced with relational databases. I'm
familiar with the basic concepts, but I haven't put them into practise very
often.
However, sometimes I get intrigued by the idea of applying relational ideas
to my domain. I sit down with pen and paper and begin coming up with
schemas. I may even start to normalize the tables at some point. At first I
feel a sort of elation that I may be on to something interesting. As I
progress I realize that it would be useful to put function pointers into the
tables. These functions are used for transforming data in some way. Then I
realize that what I seem to be doing is recreating the v-table an OOP
language is suppose to give me for free. So it's then that I feel like I'm
back where I started.
This probably doesn't even make sense, but maybe I'd make more progress if I
could apply relational ideas to objects somehow; the records in a table are
actually objects. But I'm not sure where to take the idea from there.
> Rather than one complex model I tend to gravitate towards simpler,
> application neutral, pretty dumb "atom" type objects, then I compose
> application specific "molecules" by combining "atoms". At any given
> time I pass around as small and dumb a sub-model as possible.
This relates to my work. I have a set of resusable components. The challenge
I'm primarily dealing with now after creating all of these small components
is the amount of configuration code I have to write for each application in
order to wire everything together. I'm finding I can reduce the amount of
work I have to do in this regard by using a variation of RAII, but I
digress. :-)
> Conversely if we have one big model then changing the model directly
> affects or at least threatens to affect a lot of other code.
I agree. Small models are good. I think this comes down to practising good
application partitioning.
> Anyway I was just trying to provide food for thought and advocate a
> friendly multi-paradigm approach. I don't see the need to have the
> object and relational models so violently opposed to each other ;-)
I'm intrigued by the idea, I just haven't made much progress with it. But
that doesn't mean very much. :-)
Lee Riemenschneider
wrote:
> And now we need to add Suppliers, all we need do is add a
> StockSupplier table (for many to one) and Supplier, none of the
> existing tables are changed whatsoever.
>
> But in object models you'd invariably need to edit the existing
> hierarchy and perform tree surgery, in this case the Stock class would
> probably need to have a new list of Suppliers.
>
> This is a simplistic example but hopefully it serves to illustrate how
> in the relational model you just add new relations without affecting
> anything but in the object model you usually have to edit code.
> Granted you can extend by inheritance without damage but that
> mechanism is not always the most appropriate choice.
>
In Executable UML modeling, you would add the Supplier class and an
association to the Stock class and you would be done (in a many to one
case). Reverify the model and translate into code.
> Worse still for the object model, the *one* possible snapshot is
> etched in "3G" code rather than a DDL - much more expensive to modify.
>
> No wonder RDBMs have a place in this world, you simply cannot do what
> they do with popular OO languages.
This is true, and understood by many. I'm not sure why topmind feels a
need to crusade here, after all, this isn't comp.oodbms or
comp.object.advocacy.
> If you focus on OOP instead of the job at hand - you
> are simply DOOMED.
>
Yes. Always choose the best technology for the job. I would never
claim it is always Executable UML, even if it is my preferred software
development technology.
Alvin Ryder
> "Alvin Ryder" <alvin...@telstra.com> wrote in message
Agreed, if you go *directly* from object to relational models you hit
an "impedence mismatch". But if you have an intermediate layer,
something simple like Class=Table you can go a long way to mitigating
the situation. At this intermediary level we make our OOP as
relational friendly as possible, at higher levels closer to the
application specifics we can go as ballistic with OOP as we want.
Cheers.
S Perryman
On Sep 10, 11:49 pm, "S Perryman" <a...@a.net> wrote:
AR> Anyway I was just trying to provide food for thought and advocate a
AR> friendly multi-paradigm approach. I don't see the need to have the
AR> object and relational models so violently opposed to each other ;-)
> In theory, they do not oppose eachother.
> In reality, they do.
> Primarily due to the "mismatch impedence" problem caused by the
> implementations of the prevailing RDBMS (SQL etc) , and OO prog langs
> (C++ etc) .
>Agreed, if you go *directly* from object to relational models you hit
>an "impedence mismatch". But if you have an intermediate layer,
>something simple like Class=Table you can go a long way to mitigating
>the situation. At this intermediary level we make our OOP as
>relational friendly as possible, at higher levels closer to the
>application specifics we can go as ballistic with OOP as we want.
You don't need "intermediate" anything.
The mismatch is solely down to implementation of concepts.
The prevailing RDBMS are all about defining/using properties as data values.
The prevailing OO programming systems are all about defining/using
properties
as computational behaviours.
The implementations of said property manipulations are what conflict
(representations, optimisations etc) .
But the conceptual model is mathematical. Specifically, functional.
Properties are given inputs, and produce outputs.
No surprise then that the programming paradigm that can easily support both
the OO and relational paradigm is Functional Programming.
Regards,
Steven Perryman
Alvin Ryder
wrote:
Maybe DSP programming is a great fit for OOP and you don't really have
to worry about any other forces.
But I'm not very use to a hybrid world - I should clarify by "multi-
paradigm", I don't mean "full blown paradigms", I just mean multiple
tools and ways of thinking, letting each shine and specialize in
whatever they're good at.
For business systems I'd rather have a OOP+RDBMS hybrid rather than
standing my ground with one at the detriment of the other.
In game programming this culture of "use whatever is best for each
aspect is very strong". People use OOP but they don't try to make the
world revolve around it.
If a "game engine is to games what a RDBMS is to most business
software" then I wonder why so many OOP business software developers
are so hostile to it?
In game programming, we know if you screw around with OOP at the
expense of the game engine then don't expect a good game - so we're
very nice to it ;-) (When that means going light on in the OOP
department then so be it).
Cheers.
topmind
Most dynamic languages make it fairly easy to put code in tables.
However, in practice I've found it's not needed that often, at least
in my domain, which isn't game development.
But whether such is easy or not is an implementation issue, not an
inborn paradigm issue. Existing tools tend not to make such very easy
because they are file-centric instead of database centric. But mixing
data and code is not new to OOP. Lisp made heavy use of it before OOP
was invented, for example.
>
> This probably doesn't even make sense, but maybe I'd make more progress if I
> could apply relational ideas to objects somehow; the records in a table are
> actually objects. But I'm not sure where to take the idea from there.
>
> > Rather than one complex model I tend to gravitate towards simpler,
> > application neutral, pretty dumb "atom" type objects, then I compose
> > application specific "molecules" by combining "atoms". At any given
> > time I pass around as small and dumb a sub-model as possible.
>
> This relates to my work. I have a set of resusable components. The challenge
> I'm primarily dealing with now after creating all of these small components
> is the amount of configuration code I have to write for each application in
> order to wire everything together. I'm finding I can reduce the amount of
> work I have to do in this regard by using a variation of RAII, but I
> digress. :-)
>
> > Conversely if we have one big model then changing the model directly
> > affects or at least threatens to affect a lot of other code.
>
> I agree. Small models are good. I think this comes down to practising good
> application partitioning.
>
> > Anyway I was just trying to provide food for thought and advocate a
> > friendly multi-paradigm approach. I don't see the need to have the
> > object and relational models so violently opposed to each other ;-)
>
> I'm intrigued by the idea, I just haven't made much progress with it. But
> that doesn't mean very much. :-)
-T-
Alvin Ryder
OOPS massive typo. I meant to say "But *I am* use to a hybrid
world ...". - how did that *not* get in there?
topmind
wrote:
[....]
> > No wonder RDBMs have a place in this world, you simply cannot do what
> > they do with popular OO languages.
>
> This is true, and understood by many. I'm not sure why topmind feels a
> need to crusade here, after all, this isn't comp.oodbms or
> comp.object.advocacy.
There is no (activated) "comp.object.advocacy". Thus, anything that
*would* go there goes here instead, per typical hierarchy rules. Thus,
I am not guilty of a topic sin for that one. (And OODBMS was only a
small side comment, not enough to justify a new topic over at oodbms-
land).
me.unSpank();
-T-