Re: OOP/OOD Philosophy
- From: Robert C. Martin <unclebob@xxxxxxxxxxxxxxxx>
- Date: Wed, 06 Jul 2005 19:11:38 -0500
On 6 Jul 2005 16:11:38 -0700, "topmind" <topmind@xxxxxxxxxxxxxxxx>
wrote:
>
>
>Robert C. Martin wrote:
>> On 2 Jul 2005 10:55:05 -0700, "topmind" <topmind@xxxxxxxxxxxxxxxx>
>> wrote:
>>
>> >In my domain one often cannot know ahead of time what will change.
>>
>> It's not so much a matter of knowing what will change, or even how it
>> will change. It's a matter of recognizing that certain things will
>> change at a different rate than others. For example report formats
>> are will change at a different rate than business rules.
>
>I am not sure what you mean. Both change, often at different
>unpredictable rates.
Exactly. They change at different rates. If we couple them, we will
be forced to make changes to one because of the other.
>> GUI layout
>> will change at a different rate than database schemae.
>
>Yes, but one cannot say in *advance* what will change faster.
Sometimes you can, and sometimes you can't; but it doesn't matter.
The issue is that they change for different reasons.
>Do you mean knowing the actual reason and rate? Or just knowing they
>will be different?
The latter.
>> We try not to couple report formats to business rules because it would
>> be a shame to inadvertently break the business rules by moving a
>> column on a report.
>
>Please clarify. I can think of situations where relating them may save
>time and situations where relating them would cause headaches.
I think that was pretty clear. If we couple the report format to the
business rules, (for example, by doing computations at the same time
that we are generating the report) then a change to the format of the
report will break the business rules. Or rather, when you change the
report format you'll have to make similar changes to the structure of
the business rule algorithm.
>
>> We try to decouple the GUI layout from the
>> database schemae because it would be a shame to crash the GUI when
>> adding a new column to the database.
>
>On the flip side it is sometimes nice to have a column *automatically*
>appear in the CRUD (edit screens) realm so that we don't have to make
>the same column addition in two or more different places. There is no
>One Right Coupling decision here. Adding new columns and having to sift
>through code to manually make that addition to multiple spots can be
>time-consuming.
Yes, it depends. If we are writing a program to throw away in a day
or two, then we might take a short-cut like that. On the other hand,
if we are developing a system that must survive through years of
changing requirements, then coupling the GUI to the Schema is suicide;
and the time you might save in so doing is a false economy.
-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.
- Follow-Ups:
- Re: OOP/OOD Philosophy
- From: frebe
- Re: OOP/OOD Philosophy
- From: topmind
- Re: OOP/OOD Philosophy
- References:
- Re: OOP/OOD Philosophy
- From: Nick Malik [Microsoft]
- Re: OOP/OOD Philosophy
- From: topmind
- Re: OOP/OOD Philosophy
- From: Robert C . Martin
- Re: OOP/OOD Philosophy
- From: topmind
- Re: OOP/OOD Philosophy
- Prev by Date: Re: UML Question (Object <-> ObjectFinder?)
- Next by Date: Re: OO Design induces an existential crisis
- Previous by thread: Re: OOP/OOD Philosophy
- Next by thread: Re: OOP/OOD Philosophy
- Index(es):
Loading