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.
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.
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>.
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!
"Break on thru to the other side!" --the Doors [of Perception]
> While I think procedural has been giving a short rift (often because
> 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.
> 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."
On Aug 23, 8:58 am, Phlip <phlip2...@gmail.com> wrote:
> 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
H. S. Lahman wrote: > 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 ...
> 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) ...
> > 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.
> > 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.
> > 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) ...
> H. S. Lahman wrote: > > 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 ...
Like you are so full of evidence. Full of something, but not evidence.
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.
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 wrote: >> "topmind" <topm...@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.
> > S Perryman wrote: > >> "topmind" <topm...@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" ) .
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?
On Aug 25, 6:59 pm, "Lee Riemenschneider" <newsu...@frogooa.com> 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
> 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 :
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.
> > 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.
> >> 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 :
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.
>> > 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/f92b9751ef67... > 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 ...
> >> > 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/f92b9751ef67... > > 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.
> 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 ??
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 ...
> 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 ??
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 !!!
> 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 ??
> Because that is what your "solution" is for the toy-town example.
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.
> 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.
> 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.
> > 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.
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 ;-)
> 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) .
>> 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. :-)
