Designing Objects and Systems
Bruce Eckel & Bill Venners
This seminar is available for presentation at your company
How do you think about a system and partition it into objects? What
makes a good subsystem? How do you decompose a subsystem into classes
and interfaces? This seminar will get at the essence of design by examining design tradeoffs:
- What is important
- What you should value
- How to balance usability, performance, maintainability, clarity,
This seminar is for top notch people who grasp
concepts of OO, but for whom conceptualizing the best system and object
designs is a hurdle.
The seminar consists of two parts: Designing Systems, covering the high-level issues of object-oriented architecture and system design, and Designing Objects, which will focus on the issues and questions surrounding the design of individual classes. These portions of the seminar and their associated projects will be interleaved throughout the week.
The workshop combines lectures, guided exercises, and
team-based independent work to demonstrate how object-oriented design
can work in a production environment. As with all Bruce
Eckel's seminars, the emphasis will be on getting you "thinking in"
In this portion of the seminar, you'll learn how to attack the problem of designing a system given a general set of specifications.
You will come away with:
- A hands-on understanding of a set of techniques that you can use to develop your own OO projects
- Much of the course will be a simulation exercise of the full development process described below
1. The Mission Statement & Overview Description
The inception phase should produce the key objectives of the project: what
problem are you trying to solve, and/or what service are you providing? With
some thought, this can be summarized in a couple of sentences, what I call the
Mission Statement. The value of this exercise is that, if you get stuck
in details, the mission statement can refocus you onto what you're really trying
The overview description expands on the mission statement by producing a
number of paragraphs that more completely describe the behavior of the system,
in prose. This becomes your first-cut analysis of the system, which will be used
to help produce use cases (in the following section).
Exercise: Your team will write and present the Mission Statement & Overview
Description for the exercise project.
2. Teasing out the Use Cases
The concept and value of the Use Case is introduced. This tool allows you
to describe the requirements and behavior of the system, and also to factor the
system into features that can be implemented as part of the iterative
Use cases as a minimal system specification.
Exercise: Your team will create and present use cases for the exercise
3. Identifying the Critical Risks
Product development is risk management, and the sooner you can discover and
attack the critical risks, the sooner you'll know whether your project is
feasible and what the real costs and schedule might be.
Exercise: Your team will discover and attack the critical risks for the
4. Introduction to Extreme Programming and the Importance of Automatic Testing
This section introduces the basic concepts of Extreme Programming (XP), and why it seems to work so well. How to start, using pair programming and integrated testing. The value behind creating the tests first, and how to build automated testing into your development process.
Exercise: You will write unit tests that test a Java class
5. Choosing the Initial Feature Set
Use cases can be broken into sets of features that can be selected for
implementation during particular iterations. The negotiation of the choice of
features for each iteration is an essential part of the communication between
the developers and the client, and this must be a choice made by the client
based on information about costs provided them by the developers.
Exercise: Your team factors the exercise project into features, and chooses
the initial feature set to be implemented during the first iteration.
6. Using CRC Cards to design Objects; Creating UML Class Diagrams
The primary trap of design: seduction by low-level details. How to use the 3x5
card as a constant reminder to stick to the basics of your design. Fundamentals
of UML, and UML as a communication tool. Expressing your design as a UML
Exercise: Your team uses CRC cards to discover the objects in your project.
One or more UML diagrams is created and presented.
7. The Initial Implementation Plan
Projects are built as a series of iterations. Once you've decided and designed the initial feature set, you need to get the core of the project working so that you can add features in future iterations. This also tests and proves the validity of your analysis and design, and gives valuable feedback to the customer about the state of the project, and whether it's going to accomplish the desired goals.
Exercise: Develop a plan to implement the core functionality of the project,
as decided in step 5 and designed in step 6.
The Design Project
Our presentation of the design project will include:
- The system and interactions.
- Common problems and the patterns that may help in solving them.
- Portability constraints and patterns to help solve them.
- The breadth of design alternatives and how not to be overwhelmed by them.
At the end of the week, each team will present their approach to
the solution. We will ask questions and converse about the solution choices and
possible alternative approaches. This will not be about "right and wrong"
solutions, but instead about examining decisions made based on real or imagined
constraints. Your team may want to continue your discussion over dinner and/or
at one of the local bars (everything is within easy walking distance in Crested
The "deliverables" for each project are:
- Use cases (user stories in the parlance of Extreme Programming(XP))
- The plan:
- Use cases implemented in the initial iteration and second iteraton
- Critical components that require special/up front investigation
- The design:
- UML diagrams
- Points of flexibility (where you see change happening)
- Design patterns applied to facilitate those changes
A strong emphasis will be placed on practicality and in applying the Extreme Programming (XP) principles of:
An important part of good object-oriented design is well-designed objects.
The portion of the seminar, which is called the Object Design
Workshop, focuses on guidelines and idioms that will help you create
well-designed objects. Each guideline and idiom will be explained and justified,
and then discussed by the attendees. This discussion is an integral part of the
workshop, aimed at facilitating a conversation about design among peers that can
help everyone to learn from each other's experiences and perspectives. At the
end of the Object Design Workshop, you will walk away with a specfic set of
practical guidelines and concrete idioms that you can draw upon in your future
The Object Design Workshop also includes a hands-on design project.
Periodically, the attendees of the workshop will break up into small groups,
each of which is assigned an API design project. Each group will document their
design with UML and/or javadoc HTML pages, and present their design to the rest
of the class, who will critique it mercilessly. The point of the design reviews
is the same as the discussions to draw out the experience and perspectives of
the entire group, and enable everyone to learn from each other.
The Object Design Workshop focuses heavily on designing with Java. Although
many of the guidelines are applicable to any object-oriented language, all
examples are shown in Java. Most of the idioms, by contrast, are specific to
Java. In addition, the end result of each API design project will be a Java
Here's a list of the guidelines and idioms that will be covered during the
Object Design Workshop: (Each title is linked to an online copy of the lecture
Designing with Objects
- Understand the importance of the object.
- See objects as bundles of services, not bundles of data.
- Idiom: The State Machine.
- Idiom: The Actor.
- Idiom: The Messenger.
- Idiom: The Immutable.
- Separate interface from implementation.
- Minimize the number of methods in object interfaces.
- Simplify the semantic contract of object interfaces.
- Idiom: The Event Generator.
Designing with Composition, Inheritance, and Interfaces
- Use classes to say "What objects are."
- Use class extension to model IS-A-KIND-OF relationships.
- Use composition to enlist the help of other objects.
- Understand the difference between inheritance and composition.
- Understand the significance of the interface.
- Use interfaces to say "What objects can do," or occasionally, "What can be
done to an object."
- Use interface extension to model INCLUDES-A relationships.
Designing with Types
- Make the types of your method parameters and return values as precise as
- Prefer dynamic binding to instanceof and downcasting.
- Make sure subtypes fulfill the semantic contract of their supertypes.
- Use instanceof and downcasting to ask "Can you do something for me?"
- Avoid optional clauses in semantic contracts.
- Prefer compile-time type information to run-time class information.
- Throw exceptions on abnormal conditions.
- Use a checked exception to get the attention of clients.
- Throw a different exception type for each abnormal condition.
- Idiom: The Thread-Safe Object.
- Idiom: The Hygienic Object.
- Idiom: The Canonical Object.
Articles covering most of these topics are posted at:
A high degree of comfort with object-oriented terminology. Implementation
experience with Java.
Thinking in Java, 3rd
Edition, by Bruce Eckel
Bruce Eckel's Hands-On
Recommended Reading (before the seminar):
Best Practices in Object-Oriented API Design in Java, by Bill Venners
Buy and read the following books, and bring them to the seminar:
- Extreme Programming Explained (Read Chapters 1-5)
- UML Distilled (Read Chapters 1 - 5)
What you should bring:
Your notebook computer with the latest Java development environment of your
choice loaded and tested.
A willingness to actively participate in group activities.