Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Wed, 28 Jun 2006 08:55:20 -0700
Message-ID: <2006062808552042612-unclebob_at_objectmentorcom>
On 2006-06-20 15:01:44 -0700, 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.
>
> 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?
No. Domain object should contain methods that *every* application uses. They should not contain methods that are specific to a single application.
>
>>> 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.
Unless you are adding new relationship tables that replace foreign keys.
>
>> 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?
Don't put application specific methods into the domain objects. As the
number of applications increases this gets harder and harder. In the
end, the domain objects tend to become very shallow in behavior, little
more than data structures.
>
>> 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).
Precisely! Domain objects become less and less like objects as the number of applications increases. In the end they become more like data structures than objects. The objects have been moved into the applications and are application specific.
Conclusion of this analysis is that objects and databases are distinct creatures that have no overlap. Objects belong inside applications as a structural tool for the behavior. Databases belong outside the applications, and should be used by the objects within those applications.
-- 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 Wed Jun 28 2006 - 17:55:20 CEST