Design Patterns Explained: A New Perspective on Object-Oriented Design

Design Patterns Explained: A New Perspective on Object-Oriented Design

4.5 4
by Alan Shalloway, James R. Trott
     
 

View All Available Formats & Editions

"One of the great things about the book is the way the authors explain concepts very simply using analogies rather than programming examples–this has been very inspiring for a product I'm working on: an audio-only introduction to OOP and software development."

–Bruce Eckel

"...I would expect that readers with a basic understanding of

…  See more details below

Overview

"One of the great things about the book is the way the authors explain concepts very simply using analogies rather than programming examples–this has been very inspiring for a product I'm working on: an audio-only introduction to OOP and software development."

–Bruce Eckel

"...I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely. Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns books."

–James Noble

Leverage the quality and productivity benefits of patterns–without the complexity! Design Patterns Explained, Second Edition is the field's simplest, clearest, most practical introduction to patterns. Using dozens of updated Java examples, it shows programmers and architects exactly how to use patterns to design, develop, and deliver software far more effectively.

You'll start with a complete overview of the fundamental principles of patterns, and the role of object-oriented analysis and design in contemporary software development. Then, using easy-to-understand sample code, Alan Shalloway and James Trott illuminate dozens of today's most useful patterns: their underlying concepts, advantages, tradeoffs, implementation techniques, and pitfalls to avoid. Many patterns are accompanied by UML diagrams.

Building on their best-selling First Edition, Shalloway and Trott have thoroughly updated this book to reflect new software design trends, patterns, and implementation techniques. Reflecting extensive reader feedback, they have deepened and clarified coverage throughout, and reorganized content for even greater ease of understanding. New and revamped coverage in this edition includes

  • Better ways to start "thinking in patterns"
  • How design patterns can facilitate agile development using eXtreme Programming and other methods
  • How to use commonality and variability analysis to design application architectures
  • The key role of testing into a patterns-driven development process
  • How to use factories to instantiate and manage objects more effectively
  • The Object-Pool Pattern–a new pattern not identified by the "Gang of Four"
  • New study/practice questions at the end of every chapter

Gentle yet thorough, this book assumes no patterns experience whatsoever. It's the ideal "first book" on patterns, and a perfect complement to Gamma's classic Design Patterns. If you're a programmer or architect who wants the clearest possible understanding of design patterns–or if you've struggled to make them work for you–read this book.

Read More

Product Details

ISBN-13:
9780321630049
Publisher:
Pearson Education
Publication date:
10/12/2004
Series:
Software Patterns Series
Sold by:
Barnes & Noble
Format:
NOOK Book
Pages:
480
File size:
6 MB

Read an Excerpt

Chapter 8: Expanding Our Horizons

Overview

In this chapter In previous chapters, I discussed three fundamental concepts of object-oriented design: objects, encapsulation, and abstract classes. How a designer views these concepts is important. The traditional ways are simply too limiting. In this chapter I step back and reflect on topics discussed earlier in the book. My intent is to describe a new way of seeing object-oriented design, which comes from the perspective that design patterns create.

In this chapter,

  • I compare and contrast the traditional way of looking at objects—as a bundle of data and methods—with the new way—as things with responsibilities.

  • I compare and contrast the traditional way of looking at encap-sulation— as hiding data—with the new way—as the ability to hide anything. Especially important is to see that encapsulation can be used to contain variation in behavior.

  • I compare and contrast the traditional way of using inherit-ance— for specialization and reuse—with the new way—as a method of classifying objects.

  • The new viewpoints allow for containing variation of behaviors in objects.

  • I show how the conceptual, specification, and implementation perspectives relate to an abstract class and its derived classes.
Acknowledgment

Perhaps this new perspective is not all that original. I believe that this perspective is one that many developers of the design patterns held when they developed what ended up being called a pattern. Certainly, it is a perspective that is consistent with the writings of Christopher Alexander, Jim Coplien, and the Gang of Four.

While it may not be original, it has also not been expressed in quite the way I do in this chapter and in this book. I have had to distill this way of looking at patterns from the way design patterns behave and how they have been described by others.

When I call it a new perspective, what I mean is that it is most likely a new way for most developers to view object orientation. It was certainly new to me when I was learning design patterns for the first time.

Objects: the Traditional View and the New View

The traditional view: data with methods

The traditional view of objects is that they are data with methods. One of my teachers called them "smart data." It is just a step up from a database. This view comes from looking at objects from an implementation perspective.

The new view: things with responsibilities

While this definition is accurate, as explained in Chapter 1, "The Object-Oriented Paradigm," it is based on the implementation per-spective. A more useful definition is one based on the conceptual perspective—an object is an entity that has responsibilities. These responsibilities give the object its behavior. Sometimes, I also think of an object as an entity that has specific behavior.

This is a better definition because it helps to focus on what the objects are supposed to do, not simply on how to implement them. This enables me to build the software in two steps:

1. Make a preliminary design without worrying about all of the details involved.

2. Implement the design achieved.

Ultimately, this perspective allows for better object selection and definition (in a sense, the main point of design anyway). Object definition is more flexible; by focusing on what an object does, inheritance allows us to use different, specific behaviors when needed. A focus on implementation may achieve this, but flexibility typically comes at a higher price.

It is easier to think in terms of responsibilities because that helps to define the object's public interface. If an object has a responsibility, there must be some way to ask it to perform its responsibility. How-ever, it does not imply anything about what is inside the object. The information for which the object is responsible may not even be inside the object itself.

For example, suppose I have a Shape object and its responsibilities are

  • To know where it is located

  • To be able to draw itself on a display

  • To be able to remove itself from a display
These responsibilities imply that a particular set of method calls must exist:
  • getLocation( ... )

  • drawShape( ... )

  • unDrawShape( ... )
There is no implication about what is inside of Shape. I only care that Shape is responsible for its own behaviors. It may have attributes inside it or it may have methods that calculate or even refer to other objects. Thus, Shape might contain attributes about its location or it might refer to another database object to get its location. This gives you the flexibility you need to meet your mod-eling objectives.

Interestingly, you will find that focusing on motivation rather than on implementation is a recurring theme in design patterns. Look at objects this way. Make it your basic viewpoint for objects. If you do, you will have superior designs.

Encapsulation: the Traditional View and the New View

My object-oriented umbrella

In my classes on pattern-oriented design, I often ask my students, "Who has heard encapsulation defined as ‘data hiding'?" Almost everyone raises his or her hand.

Then I proceed to tell a story about my umbrella. Keep in mind that I live in Seattle, which has a reputation for being wetter than it is, but is still a pretty wet place in the fall, winter, and spring. Here, umbrellas and hooded coats are personal friends!

Let me tell you about my great umbrella. It is large enough to get into! In fact, three or four other people can get in it with me. While we are in it, staying out of the rain, I can move it from one place to another. It has a stereo system to keep me entertained while I stay dry. Amazingly enough, it can also condition the air to make it warmer or colder. It is one cool umbrella.

My umbrella is convenient. It sits there waiting for me. It has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. Sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me!)

In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors.

Most people call them cars.

But I think of mine as an umbrella because an umbrella is some-thing you use to keep out of the rain. Many times, while I am wait-ing outside for someone to meet me, I sit in my "umbrella" to stay dry!

Definitions can be limitations

Of course, a car isn't really an umbrella. Yes, you can use it to say out of the rain, but that is too limited a view of a car. In the same way, encapsulation isn't just for hiding data. That is too limited a view of encapsulation. To think of it that way constrains my mind when I design.

How to think about encapsulation

Encapsulation should be thought of as "any kind of hiding." In other words, it can hide data. But it can also hide implementations, derived classes, or any number of things. Consider the diagram shown in Fig-ure 8-1. You might recollect this diagram from Chapter 7, "The Adapter Pattern...."

Read More

What People are saying about this

James Noble
"...I would expect that readers with a basic understanding of object-oriented programming and design would find this book useful, before approaching design patterns completely. Design Patterns Explained complements the existing design patterns texts and may perform a very useful role, fitting between introductory texts such as UML Distilled and the more advanced patterns books."

Meet the Author

Alan Shalloway is founder, CEO, and principal consultant of Net Objectives, an object-oriented consulting and training organization. An object-oriented consultant and software developer for over 20 years, he is a frequent speaker at leading development conferences, including SD Expo, Java One, OOP, and OOPSLA. He is a certified Scrum master. He is co-author of An Introduction to XML and its Family of Technologies. Shalloway holds a master's degree in computer science from MIT.

James R. Trott currently works as a senior consultant for a large financial institution in the Pacific Northwest. He has used object-oriented and pattern-based analysis techniques throughout his 20-year career in knowledge management and knowledge engineering. He holds a master of science in applied mathematics, an MBA, and a master of arts in intercultural studies.

Customer Reviews

Average Review:

Write a Review

and post it to your social network

     

Most Helpful Customer Reviews

See all customer reviews >

Design Patterns Explained: A New Perspective on Object-Oriented Design (Software Pattern Series) 4.5 out of 5 based on 0 ratings. 4 reviews.
reading_rocks_the_mind More than 1 year ago
I found this book much more accessible than the GoF Patterns book. The author provides clear, easy to understand examples of how to use design patterns and when they are appropriate.
Anonymous More than 1 year ago
Anonymous More than 1 year ago
Anonymous More than 1 year ago