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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 20 Jun 2006 14:09:24 -0400
Message-ID: <2006062014092429267-unclebob@objectmentorcom>

On 2006-06-13 09:08:35 -0400, frebe73_at_gmail.com said:

>> 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.
>

>> Changes to applications
>> have much to do with behavior and formatting, and not so much to do
>> with data.

>
> If we change the data, lets say we add a new column, phoneno, to the
> customer table, doesn't the application need to change?

Yes. But what if we add three different ways to present the phone number? Applications are certainly changed when the data is changed. However, applications are also changed with the presentation or manipulation are changed.

>

>> Since the forces that change databases and applications are different,
>> and their customers are different, they should be designed for these
>> different environments and constraints.

>
> 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.

>

>> If an application depends strongly on the database structure, then the
>> structure of its behaviors will be coupled to the database structure.
>> Since this structure is a result of catering to many different
>> applications, each application will have an indirect coupling on all
>> the others.

>
> I am not sure about your definition of "application". But in many cases
> there are only one application using a databases or multiple
> applications that all share common domain objects, that will couple
> that together anyway.

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.

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...

>

>> Or to say this a different way, the application will not
>> be able to use the data structures that are most favorable to its
>> algorithms because it is coupled to the DB whose data structures are a
>> compromise between all applications.

>
> Using views maybe?

Views are fine. They are a way to begin the translation of the data from an inconvenient form to a more convient form. But they don't aways finish the job.
>

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |

Received on Tue Jun 20 2006 - 13:09:24 CDT