Designing Objects
and Systems

A seminar on DVD
by Bruce Eckel & Bill Venners

A live, 5-day seminar on DVD, approximately 21 hours of lecture and discussion.

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 introduce you to the essence of design by examining design tradeoffs:

What is important
What you should value
How to balance usability, performance, maintainability, clarity, and flexibility.

This seminar is for software designers and programmers who grasp the 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 seminar.

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 is on “thinking in” objects.

Read comments from students

Designing Systems

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’ll get:

A hands-on understanding of a set of techniques that you can use to develop your own OO projects

A simulation exercise of the full development process described below

Sections

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

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 development process.
Use cases as a minimal system specification.
Exercise: Your team will create and present use cases for the exercise project.

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

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

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.

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:

Do the simplest thing that could possibly work
You’re not going to need it

Designing Objects

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

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 discuss it. 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 are specific to Java. In addition, the end result of each API design project will be a Java package.

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 handout.):

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, #&8220;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 possible.
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.

Guideline Grab Bag

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.

Prerequisites and Recommended Reading:

A high degree of comfort with object-oriented terminology, and implementation experience with Java are prerequisites for the course. In addition, the following books are recommended for reading before the course:

Extreme Programming Explained (Read Chapters 1-5)
UML Distilled (Read Chapters 1 - 5)

Please note:

This video is available in NTSC format only. If you live outside the USA, you must either have a DVD player that works with NTSC, or play the DVDs in your computer’s DVD drive.
This was the first video that weâ’ve made, and we used the on-camera microphone instead of lavalier microphones. As a result, the sound quality is not as good as it might have been. Please make sure you view and listen to the sample clips below to ensure that the sound quality is OK for you before purchasing this set of DVDs.