Object Design: Finding Objects
This chapter is from the book
This chapter is from the book
This chapter is from the book
Joseph Albers could make colors dance or retreat: “I see color as motion ... To put two colors together side by side really excites me. They breathe together. It’s like a pulse beat ... I like to take a very weak color and make it rich and beautiful by working on its neighbors. I can kill the most brilliant red by putting it with violet. I can make the dullest grey in the world dance by setting it against black.” Albers, one of the great graphics artists of the twentieth century, was a master at making visual imagery emerge from form and color. By careful juxtaposition of colors, textures, and shapes, the artist can make images leap off the page. Albers calls this the “1 + 1 = 3” effect. A good design is more than the sum of its parts. A bad design muddles what should be emphasized. Chartjunk—misuse of bold lines and color or addition of pretty stuff that adds no value—shifts attention away from vital information. In graphic design, composition, form, and focus are everything! An object design poses similar challenges. It is strengthened by vivid abstractions and well-formed objects that fit into an overall structure. It can be weakened by glaring inconsistencies or muddled concepts.
The abstractions you choose greatly affect your overall design. At the beginning, you have more options. As you look for candidate objects, you create and invent. Each invention colors and constrains your following choices. Initially, it’s good to seek important, vivid abstractions—those that represent domain concepts, algorithms, and software mechanisms. Highlight what’s important. If you invent too many abstractions, your design can get overly complex. Not enough abstraction, and you’ll end up with a sea of flat, lifeless objects.
Your goal is to invent and arrange objects in a pleasing fashion. Your application will be divided into neighborhoods where clusters of objects work toward a common goal. Your design will be shaped by the number and quality of abstractions and by how well they complement one another. Composition, form, and focus are everything.
A graphics designer enhances important information by layering and separating it, giving focus to the data rather than its container, and by using multiple signals to remove ambiguity.
A Discovery Strategy
So let’s get to it! Conceiving objects is a highly creative activity, but it isn’t very mysterious. Finding good candidate objects isn’t a topic that has received a lot of attention. Early object design books, including Designing Object-Oriented Software, speak of finding objects by identifying things (noun phrases) written about in a design specification. In hindsight, this approach seems naïve. Today, we don’t advocate underlining nouns and simplistically modeling things in the real world. It’s much more complicated than that. Finding good objects means identifying abstractions that are part of your application’s domain and its execution machinery. Their correspondence to real-world things may be tenuous, at best. Even when modeling domain concepts, you need to look carefully at how those objects fit into your overall application design.
Well-formed abstractions and careful attention to how they complement one another have a direct effect on the quality of an object design. This chapter discusses how to find and arrange software objects in an initial object design. The ultimate goal is to develop a practical solution that solves the problem. However, we find that such designs typically are also esthetically pleasing ones.
Although software objects aren’t just waiting for you to find them, you can identify them somewhat systematically. Although many different factors may be driving your design, there are standard places to search for objects, and you’ll find many sources of inspiration. You can use your knowledge of your application domain, your notions about needed application machinery, lessons learned from others, and your past design experience.
Our recipe for finding and assessing candidates has a number of steps:
Write a brief design story. In it, describe what is important about your application.
Using this story, identify several major themes that define some central concerns of your application.
Search for candidate objects that surround and support each theme. Draw on existing resources for inspiration: descriptions of your system’s behavior, architecture, performance, and structure.
Check that these candidates represent key concepts or things that represent your software’s view of the world outside its borders.
Look for candidates that represent additional mechanisms and machinery.
Name, describe, and characterize each candidate.
Organize your candidates. Look for natural ways to divide your application into neighborhoods—clusters of objects that are working on a common problem.
Check for their appropriateness. Test whether they represent reasonable abstractions.
Defend each candidate’s reasons for inclusion.
When discovery slows, move on to modeling responsibilities and collaborations.
This chapter will cover each of these steps in greater detail. But be aware that you don’t always complete each step before moving on to the next. The process of discovery and invention is more fluid than that. Sometimes you perform several steps at the same time. You may discard some candidates and start over if they don’t seem to fit in to your emerging design. But if you start by characterizing what is vital to your application’s success in a design story, you can then proceed with an organized search for objects that support this core.
At the end of your initial exploration, you will have several handfuls of carefully chosen, justified candidates. Many more will be invented as you proceed. These initial candidates are intentionally chosen to support some key aspect of your system. They will seed the rest of your design. Finding and inventing this first batch of candidates takes careful thought.
Initially, we recommend you look for candidate roles and objects. Once you have an idea that they’ll stick around, make decisions on how they are realized as interfaces and classes.