Building Skills in Object-Oriented Design

Why Read This Book?

The coffee-shop reason for reading this book is to provide the beginning designer with a sequence of interesting and moderately complex exercises in OO design.

If that’s all you needed to know, skip to the next chapter. It’s okay. We don’t mind.

The Problem. Some software developers find themselves stalled when trying to do object-oriented (OO) design. As programmers, they’ve understood the syntax of a programming language, and pieced together small examples. However, it is often difficult to take the next step to become a designer. The transition from guided learning of language features to self-directed design work is often ignored. Programmers are left to struggle through their first design projects without appropriate skills or support.

This may be you. You’ve learned the language, but you can’t take the next step.

While it is critically important to read examples of good design, a finished product doesn’t reveal the author’s decision-making process that created the design. There’s little support that helps a programmer come to understand the design process that leads to a final product.

The most notable consequence of this skills gap is some n00b programmers will create of software that is far more complex than necessary to effectively solve a given problem. This, in turn, leads to software with high maintenance costs stemming from the low quality. It also leads to an unfair indictment of OO technology; this is usually voiced as “we tried OO programming and it failed.”

Unrealistic Expectations. As programming team leaders, educators and consultants, we find that software development training is focused on the programming tools, but does not expose the process of creating a design. We all start out building software designed by someone else. What’s involved in design?

In the building trades, we would neither expect nor allow apprentice plumbers to design the sanitary sewage system for an urban office building. Yet, in too many Information Technology (IT) departments, software developers are expected to leap from basic training in their tools to application design.

To continue this rant, we also find that some managers are entrusted with significant projects, but are uncomfortable with OO design on modern high-performance hardware. They tend to focus their design energies on the kinds of software architectures that were appropriate when the enterprise owned a single computer, when 64 megabytes of memory was all the enterprise would ever need, and centralized disk storage was charged back to end user departments at a rate of pennies per track per month. In some organizations, there are a few enduring symptoms of this mind set in some of the ways that “end-user computing” is separated from “enterprise computing”; we relegate everything non-mainframe to second class status.

Management discomfort with OO technology surfaces in many ways. One shocking comment was that “no application needs more than six classes.” A consequence of this management attitude is an unrealistic expectation for schedule and the evolution of the deliverables.

Closing the Skills Gap. The deepeer answer on the intent of this book is to help you, the beginning designer, by giving you a sequence of interesting and moderately complex exercises in OO design. The exercises are not focused on a language, but on a design process. The exercises are not hypothetical, but must lead directly to working programs.

The long answer is that this book will make you work.

This book can also help managers develop a level of comfort with the process of OO software development. The applications we will build are a step above trivial, and will require some careful thought and design. Further, because the applications are largely recreational in nature, they are interesting and engaging. This book allows the reader to explore the processes and artifacts of OO design before project deadlines make good design seem impossible.

We hope to prevent managers from saying the following: “We had a good design, but were forced to compromise it to meet our schedule.” As consultants, we find this to be a sad statement of management’s emphasis of one near-term goal over long-term value. In one case, this was the result of a series of poorly-informed management decisions compounded on weak design skills. One of the root causes was the inability of the designers and managers to agree to a suitable course of action when a new kind of requirement made devastating changes to an existing design. We believe that more informed managers would have made a decision that created better long-term value.