Scott L Bain - The Design Patterns Companion

Scott L. Bain

Library of Congress Cataloging-in-Publication Data has been applied for.

ISBN: 978-1-62825-658-1

Published by: Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, Pennsylvania 19073-3299 USA

Phone: +1 610 356 4600

Fax: +1 610 356 4647

Email:

Internet: www.PMI.org

2020 Project Management Institute, Inc. All rights reserved.

Our copyright content is protected by U.S. intellectual property law that is recognized by most countries. To republish or reproduce our content, you must obtain our permission. Please go to http://www.pmi.org/permissions for details.

PMI, the PMI logo, PMBOK, OPM3, PMP, CAPM, PgMP, PfMP, PMI-RMP, PMI-SP, PMI-ACP, PMI-PBA, PROJECT MANAGEMENT JOURNAL, PM NETWORK, PMI TODAY, PULSE OF THE PROFESSION and the slogan MAKING PROJECT MANAGEMENT INDISPENSABLE FOR BUSINESS RESULTS. are all marks of Project Management Institute, Inc. For a comprehensive list of PMI trademarks, contact the PMI Legal Department. All other trademarks, service marks, trade names, trade dress, product names and logos appearing herein are the property of their respective owners. Any rights not expressly granted herein are reserved.

To place a Trade Order or for pricing information, please contact

Independent Publishers Group:

Independent Publishers Group

Order Department

814 North Franklin Street

Chicago, IL 60610 USA

Phone: +1 800 888 4741

Fax: +1 312 337 5985

Email: (For orders only)

For all other inquiries, please contact the PMI Book Service Center.

PMI Book Service Center

P.O. Box 932683, Atlanta, GA 31193-2683 USA

Phone: +1 866 276 4764 (within the U.S. or Canada) or +1 770 280 4129 (globally)

Fax: +1 770 280 4113

Email:

Printed in the United States of America. No part of this work may be reproduced or transmitted in any form or by any means, electronic, manual, photocopying, recording, or by any information storage and retrieval system, without prior written permission of the publisher.

The paper used in this book complies with the Permanent Paper Standard issued by the National Information Standards Organization (Z39.481984).

10 9 8 7 6 5 4 3 2 1

Introduction From the Author

Design patterns were originally delineated in the seminal work of the Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. They, in turn, were responding to an earlier work by the architect Christopher Alexander, The Timeless Way of Building. The Gang of Four's work, Design Patterns: Elements of Reusable Object-Oriented Software, received a lot of attention when it was originally published in 1994.

Some have suggested, however, that the industry has moved beyond the patterns in the more than two decades that have passed since its publication, and that in the age of agile processes and test-driven development, the patterns are no longer relevant. They say that patterns represent an old view, namely big design up front.

I disagree. Not only do I think the patterns are relevant today, I believe they are far more relevant than they were when the work was originally published. Here's why:

Patterns form a rich language of design. This is all the more important now that nearly all software projects are highly collaborative. We need reliable ways to communicate and make group decisions. Nearly all complex human activity involves specialized language: medicine, law, engineering, etc. They all have their own rich nomenclature to describe what is being proposed, or what has been done.

Patterns all follow the principles of good design in different ways. This means they are highly changeable without decay. The agile movement says, among other things, that we must embrace change. The patterns help us to do this.

This book is not meant to teach you the patterns; see the References section for books that do. This is meant to be a field guide for those who are already pattern practitioners, something to refer to as part of your day-to-day activities.

What Design Patterns Represent

The Design Patterns movement, begun (in software) by the Gang of Four (GoF) (Gamma, Helm, Johnson, & Vlissides, 1994), essentially elevated certain design elements as valuable, repeated, and high-quality examples of a particular approach to design.

Their general advice was given in three parts:

1. Design to interfaces.
2. Favor composition over inheritance.
3. Encapsulate the concept that varies.

All patterns adhere to this rubric in different ways. But they also all exhibit certain qualities of design, and they all adhere to a set of shared principles. What I will outline in the following pages are the three bits of guidance listed above, as well as how each pattern respects:

• Strong cohesion
• Proper coupling
• Robust encapsulation
• Avoiding redundancy
• Testability

In addition, I will submit that each pattern follows good principles in design, such as open-closed, the separation of concerns, and others.

I'll start with the definitions, then examine the patterns.

Design to Interfaces

Behavior in object-oriented systems is a reflection of the interaction of objects. If you change the objects or alter their interactions, the resulting behavior changes.

This means that objects have relationships to other objects, usually through references that are used to call methods. The GoF recommends that these relationships are defined based on how the objects look to each other, not by how the objects are implemented.

It's easy to misinterpret this to mean every object should have a separate interface, referring to the type interface that many languages provide. But the advice was not meant to indicate any language-specific idiom.

An interface means any defined means of communication. A method signature is an interface; the collective public methods of a class are an interface; an abstract class is an interface; etc. What is meant by that is the interface of any interaction should be based on what is needed by the clients and not the way the behavior is implemented. Changing the implementation should not affect the interface, and thus should not affect the clients.

In other words, the full version of this is design to interfaces (how you work with them) rather than implementations (what each actually does).

Favor Composition Over Inheritance

Composition/aggregation indicates a has-a relationship between objects. Inheritance, on the other hand, indicates an is-a relationship. The GoF would seem to be suggesting that you lean toward (favor) the former rather than the latter.

The potentially confusing aspect of this is that the patterns they delineate in the book use inheritance fairly extensively. Why would they recommend against this, and then do it?

Inheritance can be used for two different things:

1. To create polymorphism: Subclasses can be exchanged for each other, and can be cast to their base type, hiding their actual type from clients.
2. To specialize: Subclasses gain elements from their base class that they can accept or change, creating special versions of whatever the base class does.

What the advice means is that we should shy away from doing the latter, for the most part. If you examine the patterns, you'll see that inheritance is almost always used as a way of creating interchangeability through polymorphism.

This was also meant to disabuse designers from the notion that inheritance is for reuse. Reuse, it says, is better achieved using delegation through an interface, rather than the more intimate connection that inheritance-for-specialization creates.