Re: oo vs procedural model
Tom Forsmo wrote:
Hi
I have been reading a bit about modeling since the discussion about best
practices etc from last week and I might have made a couple of
observations I would like some feedbak on.
I think one of the problems I have regarding modelling etc is that I
tend to solve problems by database oriented solutions (hereafter called
dbo) instead of by object oriented solutions (oo). I was looking at a
simple example in Fowlers UML Distilled about an ordering system with
the objects
Order
private:
dateReceived
isPrepaid
orderNum
price
public:
dispatch()
close()
Customer
private:
name
adress
public:
creditRating()
Looking at it, its the same type of model I would have designed. But
then then I stopped to think abou how this is different to what I would
have done, i.e. how come end up with a different result than whats
described in all the books. Then I realised that this data model
describes the model that is implemented in the jvm, i.e. the live object
model.
When I design systems I usually design the same type of model, but as a
database model instead, i.e. an ER model. And then I add the java code
on top to manipulate this db model. So, the java server ends up becoming
a technical system which handles request, connections, exceptions and
some oo to db conversion, while the db is the one that does the real
manipulation and control of the information.
In contrast, an OO system would implement the datamodel in an in-memory
domain model, as described in the example model above. All manipulation
of the data is done in this model and when data needs to be saved for
safe keeping, an ORM tool or code is used to save it into an sql
database. Before any processing can be done in an OO system, data must
be read from the db and put into its objects as per the domain model,
then manipulated by the objects and written back to the db afterwords
(barring any caching techniques and so forth).
Am I on to something now? or am I still missing something
regards
tom
There are many approaches to this. The trouble is that current modern
OO systems don't "persist" well. There aren't so many tools to
manipulate already persisted object definitions, but most RDBMS allow
you to manipulate the name and number of existing columns. Because of
this, if you need to persist anything longer than a wire transfer or
system-version, you be much happier having your data definitions in
RDBMS land, rather than OO land.
The trouble becomes, OO land is arguable easier (flexible) to actually
model business logic in, so you have so many programmers that know OO
programming (not necessarily OO design), and they use an ORM to
"persist" the "object model".
Really, its a hard problem to solve, because there is a disconnect
between Relational systems and OO systems, and how they operate. You
can find a single subset of both systems, but then you've severely
limited the expressiveness and power of both systems, to the point of
almost uselessness.
<Opinion>
I think that if someone solved once and for all the long-term storage of
evolving object metadata, and some easy way to query that storage in a
functional-programming manor, RDBMS as it is will become less necessary.
</Opinion>
That is not an easy problem to solve (believe me, smart people have
tried), so we're stuck with an imbetween "ORM" layer, that translates
between the two systems. The trouble comes when you try to forget about
the translations, or the "other" layer (depending on your POV). Really,
you have an Application, that is built out of a Relational Model, and a
Object Oriented Domain Model, and a Translation Between The Two.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>