Re: OOA?

From: Roger L. Cauvin (roger_at_deadspam.com)
Date: 01/16/04 

Date: Fri, 16 Jan 2004 05:59:56 -0600

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:g77e00dsnilveih4st2d69vu52cbjob8fl@4ax.com...
> On Thu, 15 Jan 2004 13:56:31 -0600, "Roger L. Cauvin"
> <roger@deadspam.com> wrote:
>
>>You can think of the pure interfaces as corresponding to
>> the domain objects, and the classes being mere
>> implementation details.
>
> I completely agree. However, and I mean this with all
> respect, I think you are painting yourself into a corner. If
> you combine this problem with the square/rectangle problem
> then you have constrained your domain models to be
> constructed of pure interfaces that do not allow mutator
> methods.

A couple of things.

First, I don't include, or distinguish between, interfaces and classes in my
domain models. My domain models contain concepts and associations. At
design time, I compose a separate class diagram with interfaces and classes.
While no direct mapping exists, the concepts and associations in the domain
model do guide me in composing the class diagram. (And of course I iterate
on this whole process.)

Second, mutator methods in interfaces are fine as long as they don't cause
LSP problems. If a concept in the domain model (e.g. ellipse) doesn't
promise mutability, then there's a significant chance that LSP problems will
arise if the corresponding interface in the class diagram contains mutators.

> I'm not sure that most domain modelers can live with such
> constraints. I'm not sure most domain modelers
> understand the intricate issues that enforce those constraints.
> And I'm not sure that valid domain models can be
> constructed in the context of such constraints.

Domain modelers who wish to conflate conceptual models with design class
diagrams face an uphill battle in producing quality code. I don't think
it's beneficial to treat the two types of models as equivalent, and I don't
think it's realistic to expect to generate quality code directly from domain
models. 

-- 
Roger L. Cauvin
nospam_roger@cauvin.org (omit the "nospam_" part)
Cauvin, Inc.
http://www.cauvin-inc.com