Re: OOP/OOD Philosophy



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.

> GUI layout
> will change at a different rate than database schemae.

Yes, but one cannot say in *advance* what will change faster.

>
> You don't even have to know whether one will change more frequently
> than the other. You just have to be able to make a reasoned guess
> that they will change at different rates and for different reasons.

Do you mean knowing the actual reason and rate? Or just knowing they
will be different?

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

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

This is one reason I like data dictionaries: describe columns in one
and only one place and have whatever needs that info use it. I agree it
is not always that simple because it is subject to the 80-20 or 90-10
rule where 10% of the time we need a custom, local tweak that deviates
from the "standard" behavior. If we add a new data dictionary
attribute/flag for each exception (deviation), we have a big mess
(large interface) after a while. This is true with any "generic"
framework whether it be via OO, procedural, FP, etc.

(The OO equiv. of data dictionaries is a Field Object, by the way.)

BTW2, I would like to see you rework your "coupling" concept into a
change analysis and change pattern analysis focus. I think many would
find that more useful and subject to more objective observation and
metrics. One may disagree about the frequencies of certain changes (as
we seem to do), but the impact on code per change pattern is fairly
objective. Thus, the discipline can be divided into frequency analysis
and impact analysis, with the latter being more documentable thus far.

You may be well-positioned for this because most OO authors seem to
focus on "mental models" of the real world while you focus more on code
structure, which is more based on concrete,
western-reductionalist-style analysis instead of the prevalent OO fuzzy
eastern style that drives me up the wall. (Not that eastern style is
"bad", just less analyzable at this stage in history.)

>
>
> -----
> Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx

-T-

.

Relevant Pages

  • Re: Decouple SQL queries from class in OOP design
    ... Robert C. Martin wrote: ... In a good design, most of the code should be business rules. ...
    (comp.object)
  • Re: Decouple SQL queries from class in OOP design
    ... >>Robert C. Martin wrote: ... most of the code should be business rules. ... Back to the display issue. ...
    (comp.object)
  • Re: Decouple SQL queries from class in OOP design
    ... >Robert C. Martin wrote: ... most of the code should be business rules. ... A huge amount of effort goes into mapping business data into ...
    (comp.object)
  • Re: Rolling Stones
    ... claudel wrote: ... No wonder Robert hasn't aged well. ... I wondered if there was another reason for the cancellation. ... >>It definitely sounds like you have been to A LOT more concerts than me. ...
    (alt.vacation.las-vegas)
  • Re: Rolling Stones
    ... No wonder Robert hasn't aged well. ... I wondered if there was another reason for the cancellation. ... I love Las Vegas. ... Claude ...
    (alt.vacation.las-vegas)
Loading