Notes 13 Jan 2004
Domain Driven Design (VII)
Guest Author: Eric Evans

(Ken Scott-Hlebek starts with a discussion of the “Master of Software
Arts” program at UIUC. He is part of the group of students involved
in a trial run.)

Russ: Perhaps we could move on to Chapter 10? (starting p.246, Intention-Revealing
Interface)

John B: Smalltalk Best Practice Patterns, “Intention-Revealing Selector.”
I tend to think of the Java keyword for interfaces.

Russ: When you are talking about “intention revealing interface”,
is it the design-by-contract sense of syntax and semantics?

Eric: Yes, Design By Contract was one of the main factors. I don’t see
it as just the method signature.

Tracy: You’ve gone to the trouble of creating a Ubiquitous Language…I
like the way the intention-revealing interface pattern is connected. And
your example is good to show how it can be hard. “Paint.paint()”,
for example.

Russ: artPaint.GetBlue() vs. artPaint.Blue()? I’m a little surprised
you went that way.

Eric: It’s kind of entrenched as a convention in the Java world, and
it’s not too bad.

Russ: Having “create” on creational methods… it’s useful,
sometimes, to have a naming convention that is a common idiom to help
prevent surprises.

Eric: I’d like the user not to care whether they were fetching a variable
value or calculating a derived value.

John B: I’ve run into that problem.

Russ: We typically use “get” for retrieving primitive values,
like ‘int’. We use “get” a lot for accessors.

Tracy: Whether it’s calculated or not.

Russ: We don’t tend to use “compute” or “calculate”.

Mark: It’s like J2EE or JavaBeans conventions.

Phil: Yes. EJBs use the JavaBeans conventions to make introspection easier.
You can look at the JavaBean and see what state is accessible.

John B: They call it a Design Pattern but obviously it isn’t.

Phil: But it’s a convention that makes it easier to discover properties.

Mark: But even Sun, you get String.valueOf(…) etc.

Eric: But isn’t a naming convention an awkward way to put in metadata
for a tool?

Jeff: But it gets used over and over and over again. Custom attributes
in Java are the

Eric: Sometimes “has” is better than “is” for a boolean.

Mark: I’ve seen “isHas…” and “getIs…” on accessor
methods.

John C: Were these native English speakers?

Mark: Yes.

Mike: You want the convention to extend beyond is/has for your accessors.
If you enrich that language for describing, for removing ambiguity of
the interfaces, than the current state of things.

(some discussion of accessors and mutators, including conventions in
Java, Smalltalk, and Forté).

Scott: If you’re going to follow a convention that you use get…, you
shouldn’t have to care whether you fetch a field value or compute it.

Eric: It would be OK, if it were side-effect free. A lot of “calc”
methods actually modify values.

John C: Truly side-effect free? Or are you willing to have things cached?

Eric: I define it here, as no observable side effects. So caching is
OK if it’s appropriate. I don’t suppose anyone would like to make the
case against an intention-revealing interface?

John: “Too much typing?”

Jeff: “It’s such a pain to change the name of everything all the
time when you change the behavior!”

Eric: That’s the worst case, when someone has chosen a good intention-revealing
name, and someone else changes the behavior. The method name is lying
to you.

(question: should the name of iterators or index variables be long/meaningful?)

Russ: I label an iterator with the type of the instance coming out, so
iColor is an iterator over colors.

Phil: eachColor is the convention I’d use.

(internal vs. external iteration mentioned)

Phil: There are things you can do with external iterators you can’t do
with internal iterators.

Eric: But 99.9% of the time you don’t. You just run down all the items
in the collection.

Russ: But it makes you feel like a real programmer to write an iteration
loop.

(a discussion of iterators and collections, sometimes the application
is just lists, and it doesn’t matter whether you use iterators or whether
you count up via the index…)

Tim: Iterating over a 2D thing… I find that people do a better job
naming when they use iterators than when they index with integers. There
was one case where they used i and j to loop over the results, and in
one place they had misplaced an i for a j or vice versa, and something
that was supposed to be sent to one user was sent to all of them.

Eric: (discussion of a difficult case refactoring a nested loop with
embedded conditional logic)

Mike: A server test program that opened a number of sockets, one for
each thread, and sent for each socket, a number of messages, and waited
to see if each one had the proper completion token returned from the server.
So there was a loop of bursts …

Eric: Wouldn’t it have been easier to have an object to manage the threads?
Wouldn’t it have been quicker:

Mike: Probably. I just ran out of time, and it worked.

David V: Do you declare an iterator in the same scope as the loop (so
it is out of scope after the loop)? (expanded question: “Do you think
it’s important to declare a variable as close as possible to its point
of use?”)

Show of thumbs: some up, some down, several sideways.

Mike: You may need it in a larger scope, so you can’t declare it right
next to use.

Eric: Sometimes you can have a declarations section up at the top of
a method.

Phil: I put my fields up at the top of a class, certainly. Though I’ve
seen people sprinkle their fields around.

John: I use IntelliJ to write my iterators. What does it do?

Phil: So it writes the loop for you.

John C: There was a “GIST” specification language. They compared
‘declared once” specifications with “declared plus shown as
summaries”, and the ones with generated summaries were more useful.

(some extended discussion of how to organize functions, logical and physical
representation of the code, etc.)

p. 250, “Side-Effect Free Functions”

John B: So do side-effect free functions take a value object and give
you a value object back?

Eric: Sort of. Often the return value is a value object. But the connection
is rather that *every method on a value object must be a side-effect free
function*.

Phil: Couldn’t a value object function take an entity, change it and
give it back?

Eric: I wouldn’t write it that way. But maybe if the value object was
designed for that purpose. But I’d rather pass it to the entity, “change
yourself according to this transformation object”.

Tim: More like a service than a value object, that its job is to change
things?

Eric: That alone wouldn’t make it a service, but a service might do that
sort of thing.

Russ: Perhaps you could clarify this? You’re talking about changing function
arguments?

Tracy: That started with Phil’s example.

Eric: I think it’s risky business to change function arguments. A lot
about supple design is to be very obvious. Side-effect free methods are
easy to test.

John B: And to combine.

Eric: And to combine.

Russ: This kind of lets out the notion of Collecting Parameter.

Eric: When the design is exactly that, it would be sensible.

Phil: Collecting Parameter is more like a mechanism than business logic.

Eric: That might be a way to discuss Collecting Parameter, to try and
keep all the business logic out of it and put the meaning in the hands
of other objects. I don’t want to be too all-encompassing here. But you
can make things really easy to understand if you can put the complexities
onto side-effect free functions on value objects, and keeping your mutators
on your entities really simple. And having assertions (in the design by
contract sense, though they could be implemented as unit tests) on the
simple state of the entities. So client code will be really easy to understand,
as a combination of intention-revealing side-effect free functions. That’s
why these three patterns work very well together.

Russ: You’ve spent a little time thinking about this, then.

Eric: Yes, a little [spoken heavily].

John B: Closure of Operations following Standalone Classes?

Eric: Yes. This last part of the chapter is about trying to reduce the
number of dependent concepts. There are two different things here. They
both contribute to reducing interdependence. When I talk about dependencies,
I don’t mean compile-time necessarily, it’s a matter of conceptual dependency.
If you have a manager class, it doesn’t make sense out of the context
of an employee class. But perhaps depending on your model, you could understand
Employee all by itself. A genuine standalone class is one that you don’t
have to refer to other classes. Closure of an operation yields a method
that can be understand all by itself. Some of the things I talk about
here aren’t strictly closed, some of the Standalone classes aren’t completely
standalone. But if you had a class that only referred to system types,
strings and ints, these classes aren’t strictly standalone, but for practical
purposes it doesn’t add any intellectual load.

Mike: If you can move it to the next directory over, and it will still
compile and be usable by client code there, that’s a good test.

Eric: At the level of the code. Let’s say, often a street address is
a standalone class whose state consists of ints and strings.

John C: Then when you start doing business overseas, you start caring
about how an address is composed for use in other postal systems.

Eric: You could have other approaches, you could have a bunch of smart
formatters for various countries’ conventions. But most likely, as you
say, you’d model an address as a composed object.

John B: Or one big string.

Eric: There are two very important points here. Dependency is not a matter
of tracking compilation dependencies. In fact, the worst dependencies
are often ones which are implicit. For example, a class in one place which
operates on an ID, or on some object state which is represented as ints
and strings. That sort of <em>implicit</em> dependency counts.
Dependencies are very costly in terms of adding complexity. So these rules
talk about (1) Make the dependencies explicit and (2) Make them as few
as possible.

Russ: The conceptual version of coupling and cohesion.

Eric: Yes.

Russ: I know about closure of operations from mathematics. But perhaps
you could give a clearer sense of what it means here?

Eric: Operations where you put in one type and get another instance of
the same type are examples of closed operations. Selecting from a collection
gives you another collection.

Russ: So the way you wouldn’t want to do it would be to mix a pigment
and a pigment and get a paint, then pigment would not be closed over mixing,
and you’d have to be concerned whether you were dealing with a pigment
or a paint.

John B: So the part of Java’s String protocol, toUpper(), substring(),
etc. which all return String (not StringBuffer, char[], etc.), would be
a set of operations closed under String.

Eric: Closed operations are much easier to compose, and that makes them
easier to work with. The fact that they are instance methods on the same
type which they return groups them cohesively together.

Conceptual Contours (pattern)

Eric: I feel it’s very important, but I have difficulty explaining it.
It’s too much the product of intuition, I guess. Some of the ways I suggest
to find them are sort of circular.

Mark: So perhaps some of the advice is the right level of detail for
your model. Things like atoms are too fine-grained for a model of a car,
they’re outside the conceptual contour. You’d want steering wheel, tires,
etc. Not a monolithic “Car”, and not atoms.

Eric: And not front half/back half.

Jeff: Unless you’re doing finite element modeling of your car.

Russ: Conceptual distance is something you might want to discuss here.
And the sense of what concepts are close to one another. There are interesting
things (Kohonen maps) that are self-organizing clusters of concepts, ways
to get a more global picture when you’re just starting with the sense
of a bunch of individual things and their conceptual distance to one another.

Eric: That sounds like it’s the right neighborhood. As long as we don’t
get too carried away and turn it into another Rational Rose.

Russ: But a tool that understood conceptual distance could be useful
in some sense. Maybe even notifying people who are concerned with issues
that are conceptually close.

Russ: Dirk Riehle has done some work in executable UML. It might be good
to have him in to discuss the other side of things.

David: There’s this design that if you attune yourself correctly, it’s
not necessarily the code, or the diagrams, but you can talk about it.

Eric; “The model that can be named is not the true model”?

Mike: Modeling as a distraction rather than a catalytic activity. You
want a catalyst but you have a modeling language? So developing a ubiquitous
language

David: I had a professor say: “after a while, your math is in your
wrist”. But as soon as the diagram becomes “the thing”,
where it’s important, where you’re generating things off it, you can get
in some very bad places.

…

Eric: When I review this chapter (Chapter 10, “Supple Design”),
it starts out talking about how good design has this tactile quality (picture
of a bicycle), talks about some of the old Smalltalk idioms, moves on
to Design by Contract, this vague thing about Conceptual Contours. So
by the end of the chapter, the odd assortment of stuff is what you need
to accomplish the goal, a supple design that is pleasant to work with.
These pieces are not traditionally grouped, but I see a deep connection.
Do other people?

Robert: Some of each. Are they connected? Yes.

Wayne: I didn’t think of them as an odd assortment until you called it
out. Then I thought, “yes, this is a mixed bag.”

John B: Like listening to a director’s track on a DVD, they note all
the inconsistencies that you’d never notice.

Russ: Wouldn’t some other things belong here? Value Objects vs Entities
could belong here.

Eric: They show up in discussion. I didn’t want to repeat a pattern definition.
I didn’t mean it to becomprehensive, to cover all the techniques you would
use to make the design supple. But enough to convey the idea.

Mike: You are at different levels in the practices of good design. The
language connecting the pieces may need to be enriched, but the practices
are all important.

Eric: The first three patterns, to me, seem to hang together very well,
very closely. Conceptual Contours… that’s where the picture of the bicycle
comes in. You can see there are some things that are easy to take apart,
other things that are tightly bound assemblies. At the level of the designers
of a bike, the stack of gears, the gear assembly, was the part, rather
than each gear individually.

Mike: Bikes have these parts which are interchangeable to such a degree
because there are standards involved. Tolerances and specifications.

Mike: The success in communications software is based on standards. TCP/IP,
SMTP, etc.

Eric: I think that’s an example of a supple design as well. They’re well
composed, and well separated as well. The breakdown was one that allowed
for growth and adaptation.

Russ: Isn’t that a topic from chapter 14?

Eric: And those things are related, aren’t they. But I think of the Internet
protocols as a set of supple designs done right. It’s not the first thing
they came up with. The initial prototype isn’t what we have now.

Jeff: It took them at least four versions to get it right. (reference
to IPv4).

Eric: If you freeze too early, establish the standard without investigation
and practice, you end up with a stiff, awkward kind of design.

John B: “rough consensus and running code”, at least two successful
independent implementations of a proposed standard.

Jeff: And it helps if the two implementations talk to one another.

Eric: And the OMG is trying to create this standard before anyone has
actually implementing anything like it. (refering to UML support for MDA)

David V: Eric, I’m looking for a way to “sell” supple design.
So can I say, “If you use supple design, it’s less likely you’ll
have to throw away an application and rewrite it from scratch?”

Eric: Yes, it’s key to being able to hold onto your program and being
able to modify it for a long time.

David V: I was hoping your chapter conclusion would make a stronger point
of it.

Robert: That’s the whole-book benefit, rather than just the Chapter 10
benefit, right?

Russ: Chapter 10 applies even when you’re outside the domain part of
your application code.

Mike: I might express it as “Debt-free design” in the words
we used last week.

Eric: I would say that with a supple design, your project may just start
taking off at the point a conventional project would be heading for legacy
status.

Eric: Did anyone actually read Chapter 8 and the example at the end of
Chapter 10? Chapter 8 is an extended example, and the end of Chapter 10
has a more close-up view of the same transformation. Almost, that is.
It’s more like taking the stiff early version and turning it into something
supple. That’s a nice combination to get into.