Re: OOP/OOD Philosophy

> So you are saying that the paradigm can couple out to the other modules,

It is almost impossible to decouple the database paradigm from the
other modules, because changes in paradigm moves the border between
the modules. If you have a high-level pardigm (relational) and switch
to a low-level (hierachical) it is possible, because you know where the
borders are and you know what type of logic that should be classified
as "business" and "persistence". But the opposite is much harder.

For example, it is resonable to think that the next generation of
databases would have more (standardized) support for data validation
using regular expressions etc. Now we classify validation as "business"
logic. But in the future it would most likely be classified as
"persistence" logic. Do you put your validation code in the persistence
layer today, in an attempt to be prepared for the future?

> even when the actual technology is insulated.
The actual technology is not insulated. By using interfaces like JDBC
you don't need to have any idea about the underlying technology. It may
be everything from text files to DB2.

When you do software development you can't decouple from everything. I
would say that os independence is much more important than database
paradigm independence. But do you discourage people from using C# in
the same way as you discourage people from writing coupled SQL
statements? And if we choose java, we are still coupled to Sun. Every
decision about decoupling have to be resonable.

Fredrik Bertilsson
http://butler.sourceforge.net

.

Relevant Pages

  • Re: OOP/OOD Philosophy
    ... >> So you are saying that the paradigm can couple out to the other modules, ... Back in the 80s I thought it was reasonable to assume all the database ... Now what were you saying about regular expressions? ... >> even when the actual technology is insulated. ...
    (comp.object)
  • Re: Relational database & OO
    ... can be applied beyond the RDB's table/tuple paradigm. ... relationships in an RDB represent a specific implementation of the ... But no existing production database qualify as a relational database. ... Neither do the relational model or SQL. ...
    (comp.object)
  • Re: Relational database & OO
    ... The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently. ... all the business systems I've participated coding or designing spent little production time changing data. ... Given statistics like these it makes little sense to design your application or OO model before designing your database. ... And OO Class Models are routinely normalized as part of the basic paradigm methodology. ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... If you're thinking of a CRUD system, ... No, I agreed that using a database for simple create, read, ... the design relative to using OO techniques, ... All this mixing paradigm stuff is irrelavent anyhow. ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... It is almost impossible to decouple the database paradigm from the ... because changes in paradigm moves the border between ...
    (comp.object)