Why OOP Fails Domain Modeling

On Aug 23, 2:42 pm, topmind <topm...@technologist.com> wrote:
> 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-

The are many reasons object models are inferior.

Most OO languages can only support memory based models so that alone
instantly disqualifies them from many domains. They do not support
concurrent or secure user access either.

Object models tend to be closed, encasing an internal mesh of
entangled relationships. To change the model, you change the code.
This can be trivial or outrageously expensive.

In my current job they had created a large object model and used a
database merely as a "persistence mechanism". I would have advocated a
multi-paradigm and relational friendly approach but I was too late. At
any rate, now we must add a new feature which requires major new model
elements to be grafted into the model. Since they had one big model
and nearly a million lines of code a significant percentage of code
will now be impacted by this change. OUCH!

If they had smaller models and just passed minimal models around, they
would have been in a better position now.

Anyway, how would the relational model fair?

Obviously most RDBMS can handle the point about memory, concurrency
and security but better still the relational model is open. Relative
to OO it's inside out. You can add as many new relations as you need
and not affect any of the existing ones.

Consider a simple domain: Customer, Stock, Sales.

And now we need to add Suppliers, all we need do is add a
StockSupplier table (for many to one) and Supplier, none of the
existing tables are changed whatsoever.

But in object models you'd invariably need to edit the existing
hierarchy and perform tree surgery, in this case the Stock class would
probably need to have a new list of Suppliers.

This is a simplistic example but hopefully it serves to illustrate how
in the relational model you just add new relations without affecting
anything but in the object model you usually have to edit code.
Granted you can extend by inheritance without damage but that
mechanism is not always the most appropriate choice.

Another big difference is object models are merely *one* possible
snapshot of possible inter-relationships between objects. Whereas the
relational model merely defines the base ingredients (tables) and
tools to combine the ingredients (selections, joins and
projections...) you can formulate *any number of inter-relationships*,
whatever data view you require at any given time. Different
applications or parts of the same app may compose whatever they
desire.

Worse still for the object model, the *one* possible snapshot is
etched in "3G" code rather than a DDL - much more expensive to modify.

No wonder RDBMs have a place in this world, you simply cannot do what
they do with popular OO languages. So we OOP fans reluctantly concede
that point but then try to impose OO at the ORM layer - again another
great blunder. Why can't we just back off? Ignorance, pride,
stupidity?

Topmind I agree with most of your post except the point about the
"object-relational-mapping" marriage needing to be nasty. To be frank,
the ORMs I build are pretty nice to both the relational and object
camps. It just takes some mutual respect on both sides of the fence.
Granted things can turn sour real quick but if you don't let OOP
dominate especially where it is weak things do go better.

Even popular tools like Hibernate and EJB3 abuse databases. As a
result there are unnecessary performance hits, bottlenecks and other
issues. To get the most out of databases like Oracle or SQL Server you
need to give them their due respect, forget about OO for a bit. Do
what the database needs.

I'm a fan of multi-paradigm approaches, at least I try to keep
everyone happy. Prior to this gig I was doing game programming, I
loved it because there were so *many* paradigms, it wasn't just OOP
versus Relational. There's the game engine, rendering libraries
(opengl..), sound libraries, math, physics, networking,
animation, ... funny enough many of these do not use OO and they have
an obvious C heritage. Granted some have shifted to C++ but not in an
overly OO way. If you focus on OOP instead of the job at hand - you
are simply DOOMED.

Cheers

BTW. in game programming artists might use tools like 3D Studio Max
and Maya to create worlds and characters, these are then exported as a
mesh which is usually just a stream of data ... then to cut a long
story short the game engine renders that data and you see a magical 3D
world. How can this be an object model? One team of applications
creates the models and another renders it? You cannot export the code
guts from studio max. The data just has to be data.

"Alvin Ryder" wrote:

<snip>

> Consider a simple domain: Customer, Stock, Sales.
>
> And now we need to add Suppliers, all we need do is add a
> StockSupplier table (for many to one) and Supplier, none of the
> existing tables are changed whatsoever.
>
> But in object models you'd invariably need to edit the existing
> hierarchy and perform tree surgery, in this case the Stock class would
> probably need to have a new list of Suppliers.
>
> This is a simplistic example but hopefully it serves to illustrate how
> in the relational model you just add new relations without affecting
> anything but in the object model you usually have to edit code.
> Granted you can extend by inheritance without damage but that
> mechanism is not always the most appropriate choice.

When I see these sorts of examples, my question is always where does the
behavior go?

My area of programming is DSP. I deal with software models of things like
oscillators and filters. If I want, I can create a table to represent the
properties of these models. For example:

Filter Table:

ID | Cutoff Frequency | Resonance | Type
0 10000 0.5 Lowpass
1 5000 0.75 Bandpass

Great. But I need an engine to make the filter run; I need to feed a filter
an input stream which it filters and use the results. That has to go
somewhere. Instead of using tables, I use objects. The fields of a table
become the properties of the object. And as far as running the filter, all I
have to do is something like:

outputStream = filter.Process(inputStream);

So... I dunno. I've never been able to wrap my head around how a relational
model can help me realize a realtime DSP system.

On Sep 10, 3:38 pm, "Leslie Sanford" <jabberdab...@bitemehotmail.com>
wrote:
> "Alvin Ryder" wrote:
>
> <snip>
>
> > Consider a simple domain: Customer, Stock, Sales.
>
> > And now we need to add Suppliers, all we need do is add a
> > StockSupplier table (for many to one) and Supplier, none of the
> > existing tables are changed whatsoever.
>
> > But in object models you'd invariably need to edit the existing
> > hierarchy and perform tree surgery, in this case the Stock class would
> > probably need to have a new list of Suppliers.
>
> > This is a simplistic example but hopefully it serves to illustrate how
> > in the relational model you just add new relations without affecting
> > anything but in the object model you usually have to edit code.
> > Granted you can extend by inheritance without damage but that
> > mechanism is not always the most appropriate choice.
>
> When I see these sorts of examples, my question is always where does the
> behavior go?
>
> My area of programming is DSP. I deal with software models of things like
> oscillators and filters. If I want, I can create a table to represent the
> properties of these models. For example:
>
> Filter Table:
>
> ID | Cutoff Frequency | Resonance | Type
> 0 10000 0.5 Lowpass
> 1 5000 0.75 Bandpass
>
> Great. But I need an engine to make the filter run; I need to feed a filter
> an input stream which it filters and use the results. That has to go
> somewhere. Instead of using tables, I use objects. The fields of a table
> become the properties of the object. And as far as running the filter, all I
> have to do is something like:
>
> outputStream = filter.Process(inputStream);
>
> So... I dunno. I've never been able to wrap my head around how a relational
> model can help me realize a realtime DSP system.

Hi Leslie,

Good example but I don't know enough about real-time DSP systems to
even offer a suggestion. In theory the relational model can still be
used to represent your data but then you'll need a RDBMS suitable for
running in a realtime DSP environment, so I dare say we might be out
of luck there ;-)

I've worked with many game engines (although now I'm doing graphics/
java stuff) so I was in a similar boat as you in the sense that no
RDBMS could be found that co-works with game engines. But this doesn't
stop us from at least borrowing some relational ideas.

Rather than one complex model I tend to gravitate towards simpler,
application neutral, pretty dumb "atom" type objects, then I compose
application specific "molecules" by combining "atoms". At any given
time I pass around as small and dumb a sub-model as possible.

Conversely if we have one big model then changing the model directly
affects or at least threatens to affect a lot of other code.

Anyway I was just trying to provide food for thought and advocate a
friendly multi-paradigm approach. I don't see the need to have the
object and relational models so violently opposed to each other ;-)

Cheers.

"Alvin Ryder" <alvin321@telstra.com> wrote in message
news:5a024bf5-6329-424d-9b04-b2f78812c194@b2g2000prf.googlegroups.com...

> Anyway I was just trying to provide food for thought and advocate a
> friendly multi-paradigm approach. I don't see the need to have the
> object and relational models so violently opposed to each other ;-)

In theory, they do not oppose eachother.

In reality, they do.
Primarily due to the "mismatch impedence" problem caused by the
implementations of the prevailing RDBMS (SQL etc) , and OO prog langs
(C++ etc) .


Regards,
Steven Perryman

"Alvin Ryder" wrote:
> "Leslie Sanford" wrote:

<snip>

>> So... I dunno. I've never been able to wrap my head around how a
>> relational model can help me realize a realtime DSP system.
>
> Hi Leslie,
>
> Good example but I don't know enough about real-time DSP systems to
> even offer a suggestion. In theory the relational model can still be
> used to represent your data but then you'll need a RDBMS suitable for
> running in a realtime DSP environment, so I dare say we might be out
> of luck there ;-)
>
> I've worked with many game engines (although now I'm doing graphics/
> java stuff) so I was in a similar boat as you in the sense that no
> RDBMS could be found that co-works with game engines. But this doesn't
> stop us from at least borrowing some relational ideas.

I have to admit to not being very experienced with relational databases. I'm
familiar with the basic concepts, but I haven't put them into practise very
often.

However, sometimes I get intrigued by the idea of applying relational ideas
to my domain. I sit down with pen and paper and begin coming up with
schemas. I may even start to normalize the tables at some point. At first I
feel a sort of elation that I may be on to something interesting. As I
progress I realize that it would be useful to put function pointers into the
tables. These functions are used for transforming data in some way. Then I
realize that what I seem to be doing is recreating the v-table an OOP
language is suppose to give me for free. So it's then that I feel like I'm
back where I started.

This probably doesn't even make sense, but maybe I'd make more progress if I
could apply relational ideas to objects somehow; the records in a table are
actually objects. But I'm not sure where to take the idea from there.

> Rather than one complex model I tend to gravitate towards simpler,
> application neutral, pretty dumb "atom" type objects, then I compose
> application specific "molecules" by combining "atoms". At any given
> time I pass around as small and dumb a sub-model as possible.

This relates to my work. I have a set of resusable components. The challenge
I'm primarily dealing with now after creating all of these small components
is the amount of configuration code I have to write for each application in
order to wire everything together. I'm finding I can reduce the amount of
work I have to do in this regard by using a variation of RAII, but I
digress. :-)

> Conversely if we have one big model then changing the model directly
> affects or at least threatens to affect a lot of other code.

I agree. Small models are good. I think this comes down to practising good
application partitioning.

> Anyway I was just trying to provide food for thought and advocate a
> friendly multi-paradigm approach. I don't see the need to have the
> object and relational models so violently opposed to each other ;-)

I'm intrigued by the idea, I just haven't made much progress with it. But
that doesn't mean very much. :-)

On Wed, 10 Sep 2008 01:40:52 UTC, Alvin Ryder <alvin321@telstra.com>
wrote:
> And now we need to add Suppliers, all we need do is add a
> StockSupplier table (for many to one) and Supplier, none of the
> existing tables are changed whatsoever.
>
> But in object models you'd invariably need to edit the existing
> hierarchy and perform tree surgery, in this case the Stock class would
> probably need to have a new list of Suppliers.
>
> This is a simplistic example but hopefully it serves to illustrate how
> in the relational model you just add new relations without affecting
> anything but in the object model you usually have to edit code.
> Granted you can extend by inheritance without damage but that
> mechanism is not always the most appropriate choice.
>
You are generalizing. Not all object technologies are alike.

In Executable UML modeling, you would add the Supplier class and an
association to the Stock class and you would be done (in a many to one
case). Reverify the model and translate into code.

> Worse still for the object model, the *one* possible snapshot is
> etched in "3G" code rather than a DDL - much more expensive to modify.
>
Of course, Executable UML isn't 3GL.

> No wonder RDBMs have a place in this world, you simply cannot do what
> they do with popular OO languages.

This is true, and understood by many. I'm not sure why topmind feels a
need to crusade here, after all, this isn't comp.oodbms or
comp.object.advocacy.

> If you focus on OOP instead of the job at hand - you
> are simply DOOMED.
>
Yes. Always choose the best technology for the job. I would never
claim it is always Executable UML, even if it is my preferred software
development technology.


--
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 Sep 10, 11:49*pm, "S Perryman" <a...@a.net> wrote:
> "Alvin Ryder" <alvin...@telstra.com> wrote in message
>
> news:5a024bf5-6329-424d-9b04-b2f78812c194@b2g2000prf.googlegroups.com...
>
> > Anyway I was just trying to provide food for thought and advocate a
> > friendly multi-paradigm approach. I don't see the need to have the
> > object and relational models so violently opposed to each other ;-)
>
> In theory, they do not oppose eachother.
>
> In reality, they do.
> Primarily due to the "mismatch impedence" problem caused by the
> implementations of the prevailing RDBMS (SQL etc) , and OO prog langs
> (C++ etc) .
>
> Regards,
> Steven Perryman

Agreed, if you go *directly* from object to relational models you hit
an "impedence mismatch". But if you have an intermediate layer,
something simple like Class=Table you can go a long way to mitigating
the situation. At this intermediary level we make our OOP as
relational friendly as possible, at higher levels closer to the
application specifics we can go as ballistic with OOP as we want.

Cheers.

"Alvin Ryder" <alvin321@telstra.com> wrote in message
news:a96ca9cb-51e9-45ae-b99d-b7575e100505@q5g2000prf.googlegroups.com...

On Sep 10, 11:49 pm, "S Perryman" <a...@a.net> wrote:

AR> Anyway I was just trying to provide food for thought and advocate a
AR> friendly multi-paradigm approach. I don't see the need to have the
AR> object and relational models so violently opposed to each other ;-)

> In theory, they do not oppose eachother.

> In reality, they do.
> Primarily due to the "mismatch impedence" problem caused by the
> implementations of the prevailing RDBMS (SQL etc) , and OO prog langs
> (C++ etc) .

>Agreed, if you go *directly* from object to relational models you hit
>an "impedence mismatch". But if you have an intermediate layer,
>something simple like Class=Table you can go a long way to mitigating
>the situation. At this intermediary level we make our OOP as
>relational friendly as possible, at higher levels closer to the
>application specifics we can go as ballistic with OOP as we want.

You don't need "intermediate" anything.
The mismatch is solely down to implementation of concepts.

The prevailing RDBMS are all about defining/using properties as data values.
The prevailing OO programming systems are all about defining/using
properties
as computational behaviours.

The implementations of said property manipulations are what conflict
(representations, optimisations etc) .

But the conceptual model is mathematical. Specifically, functional.
Properties are given inputs, and produce outputs.

No surprise then that the programming paradigm that can easily support both
the OO and relational paradigm is Functional Programming.


Regards,
Steven Perryman

On Sep 11, 2:52*am, "Leslie Sanford" <jabberdab...@bitemehotmail.com>
wrote:
> "Alvin Ryder" wrote:
> > "Leslie Sanford" wrote:
>
> <snip>
>
> >> So... I dunno. I've never been able to wrap my head around how a
> >> relational model can help me realize a realtime DSP system.
>
> > Hi Leslie,
>
> > Good example but I don't know enough about real-time DSP systems to
> > even offer a suggestion. In theory the relational model can still be
> > used to represent your data but then you'll need a RDBMS suitable for
> > running in a realtime DSP environment, so I dare say we might be out
> > of luck there ;-)
>
> > I've worked with many game engines (although now I'm doing graphics/
> > java stuff) so I was in a similar boat as you in the sense that no
> > RDBMS could be found that co-works with game engines. But this doesn't
> > stop us from at least borrowing some relational ideas.
>
> I have to admit to not being very experienced with relational databases. I'm
> familiar with the basic concepts, but I haven't put them into practise very
> often.
>
> However, sometimes I get intrigued by the idea of applying relational ideas
> to my domain. I sit down with pen and paper and begin coming up with
> schemas. I may even start to normalize the tables at some point. At firstI
> 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. :-)

Maybe DSP programming is a great fit for OOP and you don't really have
to worry about any other forces.

But I'm not very use to a hybrid world - I should clarify by "multi-
paradigm", I don't mean "full blown paradigms", I just mean multiple
tools and ways of thinking, letting each shine and specialize in
whatever they're good at.

For business systems I'd rather have a OOP+RDBMS hybrid rather than
standing my ground with one at the detriment of the other.

In game programming this culture of "use whatever is best for each
aspect is very strong". People use OOP but they don't try to make the
world revolve around it.

If a "game engine is to games what a RDBMS is to most business
software" then I wonder why so many OOP business software developers
are so hostile to it?

In game programming, we know if you screw around with OOP at the
expense of the game engine then don't expect a good game - so we're
very nice to it ;-) (When that means going light on in the OOP
department then so be it).

Cheers.

Leslie Sanford wrote:
> "Alvin Ryder" wrote:
> > "Leslie Sanford" wrote:
>
> <snip>
>
> >> So... I dunno. I've never been able to wrap my head around how a
> >> relational model can help me realize a realtime DSP system.
> >
> > Hi Leslie,
> >
> > Good example but I don't know enough about real-time DSP systems to
> > even offer a suggestion. In theory the relational model can still be
> > used to represent your data but then you'll need a RDBMS suitable for
> > running in a realtime DSP environment, so I dare say we might be out
> > of luck there ;-)
> >
> > I've worked with many game engines (although now I'm doing graphics/
> > java stuff) so I was in a similar boat as you in the sense that no
> > RDBMS could be found that co-works with game engines. But this doesn't
> > stop us from at least borrowing some relational ideas.
>
> I have to admit to not being very experienced with relational databases. I'm
> familiar with the basic concepts, but I haven't put them into practise very
> often.
>
> However, sometimes I get intrigued by the idea of applying relational ideas
> to my domain. I sit down with pen and paper and begin coming up with
> schemas. I may even start to normalize the tables at some point. At first I
> feel a sort of elation that I may be on to something interesting. As I
> progress I realize that it would be useful to put function pointers into the
> tables. These functions are used for transforming data in some way. Then I
> realize that what I seem to be doing is recreating the v-table an OOP
> language is suppose to give me for free. So it's then that I feel like I'm
> back where I started.

Most dynamic languages make it fairly easy to put code in tables.
However, in practice I've found it's not needed that often, at least
in my domain, which isn't game development.

But whether such is easy or not is an implementation issue, not an
inborn paradigm issue. Existing tools tend not to make such very easy
because they are file-centric instead of database centric. But mixing
data and code is not new to OOP. Lisp made heavy use of it before OOP
was invented, for example.

>
> This probably doesn't even make sense, but maybe I'd make more progress if I
> could apply relational ideas to objects somehow; the records in a table are
> actually objects. But I'm not sure where to take the idea from there.
>
> > Rather than one complex model I tend to gravitate towards simpler,
> > application neutral, pretty dumb "atom" type objects, then I compose
> > application specific "molecules" by combining "atoms". At any given
> > time I pass around as small and dumb a sub-model as possible.
>
> This relates to my work. I have a set of resusable components. The challenge
> I'm primarily dealing with now after creating all of these small components
> is the amount of configuration code I have to write for each application in
> order to wire everything together. I'm finding I can reduce the amount of
> work I have to do in this regard by using a variation of RAII, but I
> digress. :-)
>
> > Conversely if we have one big model then changing the model directly
> > affects or at least threatens to affect a lot of other code.
>
> I agree. Small models are good. I think this comes down to practising good
> application partitioning.
>
> > Anyway I was just trying to provide food for thought and advocate a
> > friendly multi-paradigm approach. I don't see the need to have the
> > object and relational models so violently opposed to each other ;-)
>
> I'm intrigued by the idea, I just haven't made much progress with it. But
> that doesn't mean very much. :-)

-T-