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, and flexibility.

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" objects.

Read comments from students

Designing Systems

You will come away with:

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. 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 Butte).

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 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 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, "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.

Articles covering most of these topics are posted at:
http://www.artima.com/designtechniques/index.html

Prerequisites:

A high degree of comfort with object-oriented terminology. Implementation experience with Java.

Thinking in Java, 3rd Edition, by Bruce Eckel
or
Bruce Eckel's Hands-On Java CD

Recommended Reading (before the seminar):

Interface Design: Best Practices in Object-Oriented API Design in Java, by Bill Venners (free download)

1. Extreme Programming Explained (Read Chapters 1-5)
2. 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.