Re: Classes looking after themselves

From: SMMT (
Date: 05/20/04

  • Next message: javier g: "Hibernate and Oracle 10g"
    Date: Wed, 19 May 2004 21:57:40 -0300

    "Paul Schmidt"

    > So we really end up with 5 classes then DAOFactory, Manufacturer,
    > DAOManufacturer, Widget and DAO Widget? Or did I miss something here?

    Yes, thats right.
    It may seam alot, but it is not. The power you get by using that patterns
    overheads the number of classes. Also, the Widget and the Manufacturer would
    exist any ways , so you only implement 3 classes.

    Take this example.
    If classe A implements a SaveMe mecanis inside it for target database O , if
    you change the target Db you need to 1) rewrite the code or 2) implemmente
    another class.

    If you have N classes you need to refator N classes , losing all the N
    classes that became obsolete.

    Using the DAO Pattern you implement a factory for each project.
    Implement N DAO Objects , one for each class.
    If the target DB changes you implemente N new DAO objects. But you do not
    reimplemente the classes them selfs. And the old DAO classes are still
    You must them code N new classes, but lose nothing. Powering a plugin
    behavior for diferent target DB.
    And you may understand also that is simpler to write new code them to
    refactor old code.

    > > Of course this is a very simplistic exemplification.
    > > No flags, no mambo-jambo , no C++ tricks all Java tecnology
    > The reason for the flag is simple, if the object has not been changed,
    > then you could skip the saving step,

    You could still implement that if you really whant to.
    But is like this

    Class A implements a method like
    boolean isDirty()

    The DAO class for A in the update methos check the dity state

    if (a.isDirty() ) {
            // save

    inside each mutator on classa A you change the dirtyflag to true.

    >so this is really something else,
    > but it still seems odd that Widget needs to perform the cleanup for the
    > Manufacturer object, that is part of it. Doesn't this violate the rules
    > of object orientation?

    Well really no, but depends on theortical consideration.
    Is like this.
    A Widget has a Manufacturer like a plane has wings ?
    If yes you have a Composite relation that implies the saving of the Widget
    imples in the saving of the Manufacturer. Otherwise , you have and
    Agregation relation. That one does not implies in the saving.

    So, does a Widget has a Manufacturer like a plane has wings ?
    I think no. A widget has a reference for a manufacturer (the Widget Table
    has a foreing key for a Manufaturer table) not a manufacturer it self. (A
    Manufactuer may belong to diferente Widgets, a wing cannot belong to
    diferent planes)

     So this means that when you save the Widget with the WidgetDAO.update() it
    only will get the Manufaturer primary key and save it as a forein key. It
    does not need to save the Manufactuer object. This relation is named
    If you thing yes, them all object are saved along. Like the itens in an
    order. When you save the order you save the itens, you can't save one
    without the others. This is a must stronger relations named Composition. I
    do not think is the case of your example, but I may think so. This is
    complex highly discussed issue.

    > > The Garbase Collector is the responsable for destroying the objects, but
    > > never know when is going to operate. You have garanties the destructor
    > > run, but not when it will run.
    > >
    > But barring circumstances beyond the programs control, it will run at
    > some point, so if an object's SaveMe function is not called then adding
    > such a call to the finalize, will get it cleaned up eventually?

    That is not a good practice. Ths system must explicit save the object.
    If you expect for implict saving you may get a bad suprise.

  • Next message: javier g: "Hibernate and Oracle 10g"