Considering my personal experience and evolution on using OOP I would
advise on following Jim's advice.

From past discussion I watched on this list I believe that Jim is one
of the few mature OOP coders. There are clearly a couple of other
mature OOP coders in the list but most of them seem to be doing work on
drivers (like Jaybird) or other non core-db-engine areas. Many of the
core guys seem to still be at the stage where they think that
inheritance is one of the best OOP features.

Well, just a few years ago it looked like the whole world was thinking
that way too - me included, I'm afraid - and experience proved all of us
wrong.

Many of the fancy features in C++ that any new adopter wishes to use
(multiple inheritance and automatic type casting come to my mind) also
proved to be quite dangerous and even too expensive at debug time to be
"profitable".

All this too say that there is a significant gap of time between the
moment you thing you "get" OOP and the moment you REALLY do "get it".
Sometimes a gap of years. And during that dangerous gap of time, you are
better learning by studying the right books and articles and playing
with code that can not cause permanent damage (so, please, please stay
away of defining long lived interfaces during that time).


Have fun,
Paulo Gaspar

Jim Starkey wrote:

>Samofatov, Nickolay wrote:
>
>
>
>>There is no problem with table methods, especially if you have many
>>different programs accessing database.
>>You should be able to call them in SQL, just like you access table
>>fields.
>>
>>
>>
>>
>Why? What problem do table methods solve? Can you give us some
>examples we can bat around?
>
>
>
>>When you have all object-oriented principles implemented in database
>>existing object-oriented design and implementation methodologies become
>>directly applicable for database schema. Classical object-relational
>>mapping techniques become redundant because they are implemented in
>>database internals.
>>
>>
>>
>>
>There is a long, long history of OO guys not understanding databases and
>database guys not understanding OO. For evidence of the first, just
>look at the huge scrapheap of failed OO database companies. For
>examples of the second, you need look only as far as the Firebird 2 code
>base. Database developers have demonstrated a thorough knowledge of OO
>terminology and can toss around terms like polymorphism and
>encapsulation with the very best of them, but when it comes to writing a
>simple class with a constructor for initialization, methods to do the
>work, and a destructor to clean up, they're clueless. My guess, based
>on long experience, is that Firebird developers will have quite a
>different perspective on OO technology once they've learned to use it
>themselves.
>
>Going directly from principles to implementation without going through
>practice usually leads to unusable system.
>
>
>
>>Object-oriented design created using current approaches (UML, Booch
>>notation, etc) maps directly into database. This is good for
>>time-to-market timings and should simplify development. Business logic
>>becomes nicely encapsulated in database, but at the same time data is
>>accessible in relational form via SQL so reporting and other massive
>>operations are easy.
>>
>>Without table methods mapping object methods to relational model is
>>extremely cumbersome.
>>
>>
>>
>>
>The point is not to map object methods to the relational model, but to
>improve productivity, reliability, and performance of application
>systems. Encapsulation of methods into tables makes sense only to the
>degree that it addresses these goals. Designing a combination hair
>dryer / lawn mower is not a goal.
>
>Firebird applications are predominately written in Java, Delphi, and C.
>Two of these are already OO languages and the third has a brother
>language that can be used as an OO language. Extending database
>functionality that overlaps but clashes with host language features
>doesn't do anyone any good. The test of any proposed extensions will be
>integration with Java and Delphi that promotes productivity,
>reliability, and performance.
>
>So lets see what you've got. Sample application code at this point if
>more important than BNF.
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>