Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: <frebe73_at_gmail.com>
Date: 20 Jun 2006 15:01:44 -0700
Message-ID: <1150840904.214351.322130_at_h76g2000cwa.googlegroups.com>


> >> Applications are generally independent of each other (altough they
> >> often communicate indirectly through the DB).
> > Unless you use reusable domain objects. Lets say we have a customer
> > table, does every application has its own customer class?
> In general, yes; although some applications might share for awhile.
> Still as more and more applications are added and changed, and more and
> more application specific methods are added to the Customer class, the
> application developers will feel the pressure to separate them.

In another post you wrote:
"Domain objects do not (and should not) contain application specific functions. Any methods within them must be global to the enterprise." Isn't this a little bit contradictory?

> > What are the forces to change databases that would not also force you
> > to change the application?
> You may add a new table that has meaning to 3 out of the 10
> applications, but not to the other 7.

Yes, but decoupling will not not help you in any way in this case. Adding new tables never breaks any existing SQL statements.

> It is the job of the application designers to keep the applications
> from being coupled to on another. If the applications are coupled,
> then changing one of them causes all of tem to recompile and redeploy.

In other words: Don't use domain objects, or?

> for example, say we had a customer class. And in this customer class
> we had a print method. If some applications wanted one format for the
> printout, and others wanted a different format for the printout, we'd
> have to add more and more print functions to the customer class. Each
> new print function would force all the other applications to recompile
> and redeploy...

Another good argument for not using too much OO. Lets say you have a pre-OO approach. You have a data struct called customer, and a print function taking customer as an argument. The customer data customer could be shared by the different applications, but the different applications could have different print methods. Separation of concerns, by not using OO!!! I have always been amazing of the fact that when OO was introduced, the main argument was that data and behavior was bundled together, but in OO of today the main thing is to separate data and behavior (like it was before OO was introduced).

Fredrik Bertilsson
http://frebe.php0h.com Received on Wed Jun 21 2006 - 00:01:44 CEST

Original text of this message