|  | Why OOP Fails Domain Modeling | | |
| | | topmind |  |
|  Posted: Sat Aug 23, 2008 4:42 am Post subject: Why OOP Fails Domain Modeling |  |
| |  | |
This is a draft of an article I'm writing for my blog. Feel free to
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 | |
| | Posted: Sat Aug 23, 2008 10:43 am Post subject: Re: Why OOP Fails Domain Modeling | |
| | | |
topmind <topmind@technologist.com> writes:
| Quote: | 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 | |
| | Posted: Sat Aug 23, 2008 12:58 pm Post subject: Re: Why OOP Fails Domain Modeling | |
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!
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
LINK
blog: LINK
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
LINK
(888)OOA-PATH |
| |
| | | Phlip | |
| | Posted: Sat Aug 23, 2008 1:58 pm Post subject: Re: Why OOP Fails Domain Modeling | |
topmind writes:
| Quote: | 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]
| Quote: | While I think procedural has been giving a short rift (often because
|
"short shrift"? (-:
--
Phlip |
| |
| | | topmind | |
| | Posted: Sun Aug 24, 2008 12:58 am Post subject: Re: Why OOP Fails Domain Modeling | |
| | | |
On Aug 23, 5:43 am, Michael Ekstrand <mich...@elehack.net> wrote:
| Quote: | topmind <topm...@technologist.com> 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.
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.
|
Perhaps. In simulations you may have hundreds of items, not millions,
such that the database issue is not hanging over one's shoulder.
| Quote: |
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.
| Quote: |
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."
Thanks for your feedback.
-T- |
| |
| | | topmind | |
| | Posted: Sun Aug 24, 2008 12:59 am Post subject: Re: Why OOP Fails Domain Modeling | |
On Aug 23, 8:58 am, Phlip <phlip2...@gmail.com> wrote:
| Quote: | 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.
| Quote: | "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 | |
| | Posted: Mon Aug 25, 2008 12:30 pm Post subject: Re: Why OOP Fails Domain Modeling | |
| | | |
"topmind" <topmind@technologist.com> wrote in message
news:922fce20-1853-402e-bcc6-ca7be6909c0e@r35g2000prm.googlegroups.com...
| Quote: | 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.
| Quote: | 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 ??
| Quote: | One possibility is complexity.
|
One possibility is they use the same underlying concept for both CA and DA.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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.
| Quote: | 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 | |
| | Posted: Mon Aug 25, 2008 8:33 pm Post subject: Re: Why OOP Fails Domain Modeling | |
| | | |
S Perryman wrote:
| Quote: | "topmind" <topmind@technologist.com> wrote in message
news:922fce20-1853-402e-bcc6-ca7be6909c0e@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.
| Quote: |
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.
|
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.
| Quote: |
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.
| Quote: |
And so on (if I could be arsed - but the reader with assumed nominal
intelligence gets the point) ...
|
Insults do not truth make.
| Quote: |
Regards,
Steven Perryman
|
-T- |
| |
| | | Lee Riemenschneider | |
| | Posted: Tue Aug 26, 2008 1:59 am Post subject: Re: Why OOP Fails Domain Modeling | |
On Sat, 23 Aug 2008 04:42:31 UTC, topmind <topmind@technologist.com>
wrote:
| Quote: | 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.
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! LINK |
| |
| | | S Perryman | |
| | Posted: Tue Aug 26, 2008 4:23 am Post subject: Re: Why OOP Fails Domain Modeling | |
| | | |
"topmind" <topmind@technologist.com> wrote in message
news:eb83cca3-de4a-488c-89e4-a84ac33c2da4@n38g2000prl.googlegroups.com...
| Quote: | S Perryman wrote:
"topmind" <topmind@technologist.com> wrote in message
news:922fce20-1853-402e-bcc6-ca7be6909c0e@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 |
| |
| Page 1 of 4 .:. Goto page 1, 2, 3, 4 Next | |
|
|
