Re: Clean Object Class Design -- What is it?

In article <9i5shf$s07$0_at_pita.alt.net>, Chris Smith says...
>
>"Mikito Harakiri" <nospam_at_newsranger.com> wrote ...
>> > The question is, if the data is globally accessible
>> > via a given API from a central location, through an OOP-style remote
 call
>> > interface, then why is this a bad thing?
>>
>> Because making calls through APIs -- object or not -- is inferior to
 quering.
>> You are essentially limited by the design what API developers thought the
 access
>> path to the database might be. Every time you need to do something that
 they
>> didn't envision, you have to beg them with enhancement request.
>
>Certainly, there are some limitations... for example, you really have to get
>back objects, or even entire object graphs, from the query, rather than a
>few discretely chosen columns here and there.

It's amaisingly easy to serialize the whole object graph, right. It is hard to extract a portion of object graph because immediately we are faced with consistency problems. Object subgraph boundary is where those pointers must be exposed and add to whole model complexity.

>However, these are the
>limitations that get enforced anyway, merely from the fact that access to
>the data is done in an object-oriented manner.

I'm suspecting those limitations to be arbitrary.

>Now, I'm not claiming that these kinds of products are appropriate for
>highly mathematical or statistical analysis applications, where the
>flexibility of SQL as a query language can actually help. I'm saying that
>when working in a business application setting, using an OO programming
>model anyway, there's no real gain from the relational database except as a
>back end to an object store.

I didn't ever see any useful business object. Artifacts of implementation: windows, other gui controls, all sorts of collections - definetely - but never objects with any realistic business behaviour. Oh, yes too often people put some attributes together, getter/setter methods, add some storage methods and call them business objects; but those are just implementation artifacts. Strip them out of persistence and gui related clothes and there is nothing left upon them. Plane.fly() works in OO books only, I'm afraid.

Therefore, I would claim exactly the opposite: working with relational model anyway, there's no real gain from the objects except as a using some GUI libraries. I just want to display my data from the database, and gui controls is the only abstraction I need.

>I've worked in both models, and have never had
>problems with the object store-based software having "esotric update
>anomalies" (which I wish Bob had explained more before he degenerated into
>insults).

Concurrency models are also intrincically more complex for object structures than for relations.

>> Object Oriented programming is easier to learn, because there is no
 substance to
>> it.
>
>Yet, in my experience, both are sufficient to solve the problems at hand in
>business-level programming. The difficult problems, in *both* class
>modeling and relational database modeling, pertain to identifying the exact
>business requirements and components and rules. If relational database
>models make things easier, the things they make easier haven't been the
>things that have bothered me... and I've failed to notice. So it makes
>sense, to me, to do just one and let that imply the other. That's exactly
>the idea behind an ODBMS, or an object-relational mapping such as the one I
>mentioned to Bob, or perhaps EJB's CMP technology, or some other kind of
>direct object data store that doesn't require explicitly coding a mapping
>between the two.

I don't know. At some point I was searching for an answer how do people define object relational mapping. I looked into TopLink manual and their answer was: on left side of the mapper panel are the tables, on the right right side are the objects and we have 15 buttons for you to marry those folks. 15 different kind of mappings, gimme a break! And later at the end of the manual: object relational mapping sometimes can bring very complicated problems, but we have our consultants ready to help you... Received on Sun Jul 22 2001 - 01:34:12 CEST