|
The video of the original talk is available online at the InfoQ website: http://www.infoq.com/presentations/What-Drives-Design-Rebecca-Wirfs-Brock Rebecca Wirfs-Brock delivered an invited talk at OOPSLA 2008. The talk had two main threads. First,
Rebecca presented some of the concepts in her own "driven" methodology, Responsibility Driven Design (RDD). Second,
Rebecca presented a comparison of several different "driven" approaches to software design and development - development driven
by features (FDD), unit tests (TDD), behavior (BDD), contracts (CDD), models (MDD), agile models (AMDD), and domains (DDD).
Part 1: Overview of RDD
In the initial section of the presentation, Rebecca highlighted several important characteristics of Responsibility Driven
Design:
1. RDD was an attempt by Smalltalk developers to move away from data-centric design planning -- moving
instead in the direction using the list of behaviors or member functions to define encapsulated classes.
The biggest drawback of designing data-centric encapsulations (where classes focus first on data structures and data relationships)
is that the implementation details start to drive the design.
2. Using CRC cards to do the initial design planning
has been a good way to get the designers to give up global knowledge of control. Each class or object has the local
knowledge to accomplish its part of a task. This approach reduces the number of gratuitous global variables and unnecessary
pointers. The approach also attempts to make each class cleaner and simpler, so a class implementation is not inappropriately
reliant on the knowledge of the implementation of other objects.
3. The CRC brainstorming process creates a set
of "candidates" -- which might sometimes be individual classes or might instead be implemented as a set of classes.
If we think of our objects at a higher level than just a class declaration in our favorite language, we will defer some of
the details of the design until later. This gives us time to let the detailed design and implementation unfold over
time.
4. The book Object Design (2002) by Rebecca Wirfs-Brock and Alan McKean introduces the concept
of "role stereotypes", which is a useful way to think about the primary responsibilities of each class. The book also
presents the idea of "control style" (centralized, delegated, and dispersed).
Part 2: Other xDD approaches
Here are some insights from the discussion of other "driven" design approaches:
1. Some of the design approaches
have a faster or slower "rhythm".
- For example, TDD has a fast rhythm, because an individual developer (or a pair of developers) works "story by story" in
planning the design and "test by test" in the process of filling in the implementation details.
- But in FDD, the design rhythm is "feature by feature" -- a small team works together to build or extend a design
model, then write code and inspect code that implements the updated model.
- AMDD (Agile Model-Driven Development from Scott Ambler) works in small steps -- alternating between the process of
"modeling to understand" and "coding".
2. BDD, DDD, and CDD focus on different key artifacts.
- BDD can be thought of as a subtle variation of TDD. The core artifacts are the "behavior specifications", which
are a kind of functional test.
- DDD is focused on creating an object model where the names of the objects and operations are drawn from the vocabulary
of domain experts.
- CDD (contract-driven) focuses on formal specifications of the behavior of individual methods (input values, output
values, preconditions, postconditions, and invariants)
3. Is it a good idea to "mix" practices and concepts from multiple xDD methods? Rebecca posed this notion of mixing
CDD and TDD in an online discussion forum and received three different reactions:
- It isn't too bad, because the practices seem to be complementary.
- It isn't good at all, and it is better to focus on getting one practice right.
- It is heresy: you just dilute one practice by mixing it with another.
Rebecca thinks mixing practices is a good thing: it is short-sighted to follow one approach strictly. It is
better to blend design techniques to help create designs that are expressive, understood, hang together, are usable and testable,
and support design evolution and change.
4. Rebecca proposes some properties of good design that are drawn from the "15 properties of things that have life" in
Christopher Alexander's book The Nature of Order:
- "Levels of scale" -- Designers must consider different levels of scale when they evaluate the goodness of their design
choices -- conceptual level (responsibilities), specification level (class interfaces, method signatures), implementation
level (code, data, schemas).
- "Strong centers" are essential to a good design -- and each of the "driven" design can contribute to this property.
For example, CDD has contracts that are specified outside of the method implementation, and the contracts can make the implementation
simpler and better focused. The "design centers" are also strengthened by having well-defined interfaces -- a practice
that is supported by many of the xDD approaches.
- "Local Symmetries" is a property that creates coherence in a design -- and most of the xDD methods support the realization
of meaningful symmetry, not just blindly defining "setters" corresponding to each "getter". The important design symmemtries
are use of a common design language, consistent naming schemes, and consistent level of code detail.
- "Deep Interlock and Ambiguity" is a subtle property -- most software designs need to support change, and that means
the interactions between software components will change. When we build our systems, we don't just click together a
fixed set of standard components. Our design techniques need to deal with dynamic contractual specifications.
Our design techniques will have to ensure that the collaborations in our design remain valid as the design evolves.
Rebecca's conclusions: Many different design approaches are useful and some of the approaches can be blended successfully.
The goal of good design is to build "livable" or "habitable" software (software that other developers enjoy working with).
It isn't so good to be compulsive ("driven in a bad sense") and to blindly follow one approach. We need to consider
using "the right tool for the job" if we want to build sustainable software.
|
