THE EXPERT’S VOICE® IN JAVA
Java Design Patterns
A Tour with 23 Gang of Four Design Patterns in Java
Vaskaran Sarcar
Java Design Patterns
A Tour of 23 Gang of Four Design Patterns in Java
Vaskaran Sarcar
Java Design Patterns: A tour of 23 gang of four design patterns in Java
Copyright © 2016 by Vaskaran Sarcar
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location, in its current version, and permission for use must always be obtained from Springer. Permissions for use may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution under the respective Copyright Law.
ISBN-13 (pbk): 978-1-4842-1801-3 ISBN-13 (electronic): 978-1-4842-1802-0
Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein.
Managing Director: Welmoed Spahr
Lead Editor: Pramila Balan
Technical Reviewers: Anupam Chakraborty and Shekar Maravi
Editorial Board: Steve Anglin, Pramila Balan, Louise Corrigan, Jonathan Gennick, Robert Hutchinson,
Celestin Suresh John, Michelle Lowman, James Markham, Susan McDermott, Matthew Moodie,
Jeffrey Pepper, Douglas Pundick, Ben Renow-Clarke, Gwenan Spearing Coordinating Editor: Prachi Mehta
Copy Editor: Karen Jameson
Compositor: SPi Global
Indexer: SPi Global Artist: SPi Global
Distributed to the book trade worldwide by Springer Nature, 233 Spring Street, 6th Floor, New York,
NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation.
For information on translations, please e-mail rights@apress.com, or visit www.apress.com.
Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Special Bulk Sales–eBook Licensing web page at www.apress.com/bulk-sales.
Any source code or other supplementary materials referenced by the author in this text is available to readers at www.apress.com/9781484218013. For detailed information about how to locate your book’s source code, go to www.apress.com/source-code/. Readers can also access source code at SpringerLink in the Supplementary Material section for each chapter.
Dedicated to Almighty GOD
My Family
and
The Gang of Four You are my inspiration.
Contents at a Glance
About the Author ���������������������������������������������������������������������������������������������������xvii Acknowledgments ��������������������������������������������������������������������������������������������������xix Preface �������������������������������������������������������������������������������������������������������������������xxi Key Points�������������������������������������������������������������������������������������������������������������xxiii
■Chapter 1: Introduction ����������������������������������������������������������������������������������������� 1 ■Chapter 2: Observer Patterns �������������������������������������������������������������������������������� 3 ■Chapter 3: Singleton Patterns������������������������������������������������������������������������������ 17 ■Chapter 4: Proxy Patterns ����������������������������������������������������������������������������������� 23 ■Chapter 5: Decorator Patterns����������������������������������������������������������������������������� 27 ■Chapter 6: Template Method Patterns ����������������������������������������������������������������� 33 ■Chapter 7: Strategy Patterns (Or, Policy Patterns)����������������������������������������������� 39 ■Chapter 8: Adapter Patterns �������������������������������������������������������������������������������� 47 ■Chapter 9: Command Patterns����������������������������������������������������������������������������� 53 ■Chapter 10: Iterator Patterns������������������������������������������������������������������������������� 59 ■Chapter 11: Facade Patterns ������������������������������������������������������������������������������� 67 ■Chapter 12: Factory Method Patterns������������������������������������������������������������������ 73 ■Chapter 13: Memento Patterns���������������������������������������������������������������������������� 77 ■Chapter 14: State Patterns ���������������������������������������������������������������������������������� 83 ■Chapter 15: Builder Patterns ������������������������������������������������������������������������������� 89 ■Chapter 16: Flyweight Patterns ��������������������������������������������������������������������������� 97
v
■ Contents at a GlanCe
■Chapter 17: Abstract Factory Patterns �������������������������������������������������������������� 109 ■Chapter 18: Mediator Patterns �������������������������������������������������������������������������� 115 ■Chapter 19: Prototype Patterns ������������������������������������������������������������������������� 123 ■Chapter 20: Chain of Responsibility Patterns ���������������������������������������������������� 129 ■Chapter 21: Composite Patterns������������������������������������������������������������������������ 135 ■Chapter 22: Bridge Patterns (Or Handle/Body Patterns) ����������������������������������� 141 ■Chapter 23: Visitor Patterns ������������������������������������������������������������������������������ 149 ■Chapter 24: Interpreter Patterns ����������������������������������������������������������������������� 155 ■Appendix A: FAQ ������������������������������������������������������������������������������������������������ 163
Index��������������������������������������������������������������������������������������������������������������������� 169
vi
Contents
About the Author ���������������������������������������������������������������������������������������������������xvii Acknowledgments ��������������������������������������������������������������������������������������������������xix Preface �������������������������������������������������������������������������������������������������������������������xxi Key Points�������������������������������������������������������������������������������������������������������������xxiii
■Chapter 1: Introduction ����������������������������������������������������������������������������������������� 1 ■Chapter 2: Observer Patterns �������������������������������������������������������������������������������� 3 Concept ���������������������������������������������������������������������������������������������������������������������������� 3 Real-Life Example ������������������������������������������������������������������������������������������������������������ 3 Computer World Example ������������������������������������������������������������������������������������������������� 3 Illustration ������������������������������������������������������������������������������������������������������������������������ 3 UML Class Diagram ���������������������������������������������������������������������������������������������������������� 4 Package Explorer view ����������������������������������������������������������������������������������������������������� 5 Implementation ���������������������������������������������������������������������������������������������������������������� 5 Output������������������������������������������������������������������������������������������������������������������������������� 7 Note���������������������������������������������������������������������������������������������������������������������������������� 7 UML Class Diagram ���������������������������������������������������������������������������������������������������������� 8 Package Explorer view ����������������������������������������������������������������������������������������������������� 8 Implementation ���������������������������������������������������������������������������������������������������������������� 9 Output����������������������������������������������������������������������������������������������������������������������������� 11 Assignment �������������������������������������������������������������������������������������������������������������������� 11
vii
■ Contents
UML Class Diagram �������������������������������������������������������������������������������������������������������� 11 Implementation �������������������������������������������������������������������������������������������������������������� 12 Output����������������������������������������������������������������������������������������������������������������������������� 15
■Chapter 3: Singleton Patterns������������������������������������������������������������������������������ 17 Concept �������������������������������������������������������������������������������������������������������������������������� 17 Real-Life Example ���������������������������������������������������������������������������������������������������������� 17 Computer World Example ����������������������������������������������������������������������������������������������� 17 Illustration ���������������������������������������������������������������������������������������������������������������������� 17 UML Class Diagram �������������������������������������������������������������������������������������������������������� 18 Package Explorer view ��������������������������������������������������������������������������������������������������� 18 Implementation �������������������������������������������������������������������������������������������������������������� 18 Output����������������������������������������������������������������������������������������������������������������������������� 19 Note�������������������������������������������������������������������������������������������������������������������������������� 20
■Chapter 4: Proxy Patterns ����������������������������������������������������������������������������������� 23 Concept �������������������������������������������������������������������������������������������������������������������������� 23 Real–Life Example���������������������������������������������������������������������������������������������������������� 23 Computer World Example ����������������������������������������������������������������������������������������������� 23 Illustration ���������������������������������������������������������������������������������������������������������������������� 23 UML Class Diagram �������������������������������������������������������������������������������������������������������� 24 Package Explorer view ��������������������������������������������������������������������������������������������������� 24 Implementation �������������������������������������������������������������������������������������������������������������� 25 Output����������������������������������������������������������������������������������������������������������������������������� 26 Note�������������������������������������������������������������������������������������������������������������������������������� 26
■Chapter 5: Decorator Patterns����������������������������������������������������������������������������� 27 Concept �������������������������������������������������������������������������������������������������������������������������� 27 Real-Life Example ���������������������������������������������������������������������������������������������������������� 27 Computer World Example ����������������������������������������������������������������������������������������������� 27 Illustration ���������������������������������������������������������������������������������������������������������������������� 27
viii
UML Class Diagram �������������������������������������������������������������������������������������������������������� 28 Package Explorer view ��������������������������������������������������������������������������������������������������� 29 Implementation �������������������������������������������������������������������������������������������������������������� 29 Output����������������������������������������������������������������������������������������������������������������������������� 31 Note�������������������������������������������������������������������������������������������������������������������������������� 31
■Chapter 6: Template Method Patterns ����������������������������������������������������������������� 33 Concept �������������������������������������������������������������������������������������������������������������������������� 33 Real-Life Example ���������������������������������������������������������������������������������������������������������� 33 Computer World Example ����������������������������������������������������������������������������������������������� 33 Illustration ���������������������������������������������������������������������������������������������������������������������� 33 UML Class Diagram �������������������������������������������������������������������������������������������������������� 34 Package Explorer view ��������������������������������������������������������������������������������������������������� 35 Implementation �������������������������������������������������������������������������������������������������������������� 35 Output����������������������������������������������������������������������������������������������������������������������������� 37 Note�������������������������������������������������������������������������������������������������������������������������������� 37
■Chapter 7: Strategy Patterns (Or, Policy Patterns)����������������������������������������������� 39 Concept �������������������������������������������������������������������������������������������������������������������������� 39 Real–Life Example���������������������������������������������������������������������������������������������������������� 39 Computer World Example ����������������������������������������������������������������������������������������������� 39 Illustration ���������������������������������������������������������������������������������������������������������������������� 39 UML Class Diagram �������������������������������������������������������������������������������������������������������� 40 Package Explorer view ��������������������������������������������������������������������������������������������������� 41 Implementation �������������������������������������������������������������������������������������������������������������� 41 Output����������������������������������������������������������������������������������������������������������������������������� 44 Note�������������������������������������������������������������������������������������������������������������������������������� 45
■ Contents
ix
■ Contents
■Chapter 8: Adapter Patterns �������������������������������������������������������������������������������� 47 Concept �������������������������������������������������������������������������������������������������������������������������� 47 Real–Life Example���������������������������������������������������������������������������������������������������������� 47 Computer World Example ����������������������������������������������������������������������������������������������� 47 Illustration ���������������������������������������������������������������������������������������������������������������������� 47 UML Class Diagram �������������������������������������������������������������������������������������������������������� 48 Package Explorer view ��������������������������������������������������������������������������������������������������� 49 Implementation �������������������������������������������������������������������������������������������������������������� 49 Output����������������������������������������������������������������������������������������������������������������������������� 50 Note�������������������������������������������������������������������������������������������������������������������������������� 51 Illustration ���������������������������������������������������������������������������������������������������������������������� 51 Output����������������������������������������������������������������������������������������������������������������������������� 52
■Chapter 9: Command Patterns����������������������������������������������������������������������������� 53 Concept �������������������������������������������������������������������������������������������������������������������������� 53 Real-Life Example ���������������������������������������������������������������������������������������������������������� 53 Computer World Example ����������������������������������������������������������������������������������������������� 53 Illustration ���������������������������������������������������������������������������������������������������������������������� 53 UML Class Diagram �������������������������������������������������������������������������������������������������������� 54 Package Explorer view ��������������������������������������������������������������������������������������������������� 55 Implementation �������������������������������������������������������������������������������������������������������������� 55 Output����������������������������������������������������������������������������������������������������������������������������� 57 Note�������������������������������������������������������������������������������������������������������������������������������� 57
■Chapter 10: Iterator Patterns������������������������������������������������������������������������������� 59 Concept �������������������������������������������������������������������������������������������������������������������������� 59 Real-Life Example ���������������������������������������������������������������������������������������������������������� 59 Computer World Example ����������������������������������������������������������������������������������������������� 59 Illustration ���������������������������������������������������������������������������������������������������������������������� 59 UML Class Diagram �������������������������������������������������������������������������������������������������������� 60
x
Package Explorer view ��������������������������������������������������������������������������������������������������� 61 Implementation �������������������������������������������������������������������������������������������������������������� 61 Output����������������������������������������������������������������������������������������������������������������������������� 65 Note�������������������������������������������������������������������������������������������������������������������������������� 65
■Chapter 11: Facade Patterns ������������������������������������������������������������������������������� 67 Concept �������������������������������������������������������������������������������������������������������������������������� 67 Real-Life Example ���������������������������������������������������������������������������������������������������������� 67 Computer World Example ����������������������������������������������������������������������������������������������� 67 Illustration ���������������������������������������������������������������������������������������������������������������������� 67 UML Class Diagram �������������������������������������������������������������������������������������������������������� 68 Package Explorer view ��������������������������������������������������������������������������������������������������� 68 Implementation �������������������������������������������������������������������������������������������������������������� 69 Output����������������������������������������������������������������������������������������������������������������������������� 71 Note�������������������������������������������������������������������������������������������������������������������������������� 71
■Chapter 12: Factory Method Patterns������������������������������������������������������������������ 73 Concept �������������������������������������������������������������������������������������������������������������������������� 73 Real-Life Example ���������������������������������������������������������������������������������������������������������� 73 Computer World Example ����������������������������������������������������������������������������������������������� 73 Illustration ���������������������������������������������������������������������������������������������������������������������� 73 UML Class Diagram �������������������������������������������������������������������������������������������������������� 74 Package Explorer view ��������������������������������������������������������������������������������������������������� 74 Implementation �������������������������������������������������������������������������������������������������������������� 75 Output����������������������������������������������������������������������������������������������������������������������������� 76 Note�������������������������������������������������������������������������������������������������������������������������������� 76
■Chapter 13: Memento Patterns���������������������������������������������������������������������������� 77 Concept �������������������������������������������������������������������������������������������������������������������������� 77 Real-Life Example ���������������������������������������������������������������������������������������������������������� 77 Computer World Example ����������������������������������������������������������������������������������������������� 77
■ Contents
xi
■ Contents
Illustration ���������������������������������������������������������������������������������������������������������������������� 77 UML Class Diagram �������������������������������������������������������������������������������������������������������� 78 Package Explorer view ��������������������������������������������������������������������������������������������������� 79 Implementation �������������������������������������������������������������������������������������������������������������� 79 Output����������������������������������������������������������������������������������������������������������������������������� 81 Note�������������������������������������������������������������������������������������������������������������������������������� 81
■Chapter 14: State Patterns ���������������������������������������������������������������������������������� 83 Concept �������������������������������������������������������������������������������������������������������������������������� 83 Real-Life Example ���������������������������������������������������������������������������������������������������������� 83 Computer World Example ����������������������������������������������������������������������������������������������� 83 Illustration ���������������������������������������������������������������������������������������������������������������������� 83 UML Class Diagram �������������������������������������������������������������������������������������������������������� 84 Package Explorer view ��������������������������������������������������������������������������������������������������� 85 Implementation �������������������������������������������������������������������������������������������������������������� 85 Output����������������������������������������������������������������������������������������������������������������������������� 87 Note�������������������������������������������������������������������������������������������������������������������������������� 87
■Chapter 15: Builder Patterns ������������������������������������������������������������������������������� 89 Concept �������������������������������������������������������������������������������������������������������������������������� 89 Real-Life Example ���������������������������������������������������������������������������������������������������������� 89 Computer World Example ����������������������������������������������������������������������������������������������� 89 Illustration ���������������������������������������������������������������������������������������������������������������������� 89 UML Class Diagram �������������������������������������������������������������������������������������������������������� 90 Package Explorer view ��������������������������������������������������������������������������������������������������� 91 Implementation �������������������������������������������������������������������������������������������������������������� 92 Output����������������������������������������������������������������������������������������������������������������������������� 94 Note�������������������������������������������������������������������������������������������������������������������������������� 95
xii
■Chapter 16: Flyweight Patterns ��������������������������������������������������������������������������� 97 Concept �������������������������������������������������������������������������������������������������������������������������� 97 Real-Life Example ���������������������������������������������������������������������������������������������������������� 97 Computer World Example ����������������������������������������������������������������������������������������������� 97 Illustration ���������������������������������������������������������������������������������������������������������������������� 97 UML Class Diagram �������������������������������������������������������������������������������������������������������� 98 Package Explorer view ��������������������������������������������������������������������������������������������������� 98 Implementation �������������������������������������������������������������������������������������������������������������� 99 Output��������������������������������������������������������������������������������������������������������������������������� 102 Improvement to the program ��������������������������������������������������������������������������������������� 102 UML Class Diagram ������������������������������������������������������������������������������������������������������ 103 Package Explorer view ������������������������������������������������������������������������������������������������� 104 Implementation ������������������������������������������������������������������������������������������������������������ 104 Output��������������������������������������������������������������������������������������������������������������������������� 107 Note������������������������������������������������������������������������������������������������������������������������������ 107
■Chapter 17: Abstract Factory Patterns �������������������������������������������������������������� 109 Concept ������������������������������������������������������������������������������������������������������������������������ 109 Real-Life Example �������������������������������������������������������������������������������������������������������� 109 Computer World Example ��������������������������������������������������������������������������������������������� 109 Illustration �������������������������������������������������������������������������������������������������������������������� 109 UML Class Diagram ������������������������������������������������������������������������������������������������������ 110 Package Explorer view ������������������������������������������������������������������������������������������������� 111 Implementation ������������������������������������������������������������������������������������������������������������ 111 Output��������������������������������������������������������������������������������������������������������������������������� 114 Note������������������������������������������������������������������������������������������������������������������������������ 114
■ Contents
xiii
■ Contents
■Chapter 18: Mediator Patterns �������������������������������������������������������������������������� 115 Concept ������������������������������������������������������������������������������������������������������������������������ 115 Real-Life Example �������������������������������������������������������������������������������������������������������� 115 Computer World Example ��������������������������������������������������������������������������������������������� 115 Illustration �������������������������������������������������������������������������������������������������������������������� 116 UML Class Diagram ������������������������������������������������������������������������������������������������������ 116 Package Explorer view ������������������������������������������������������������������������������������������������� 117 Implementation ������������������������������������������������������������������������������������������������������������ 117 Output��������������������������������������������������������������������������������������������������������������������������� 121 Note������������������������������������������������������������������������������������������������������������������������������ 121
■Chapter 19: Prototype Patterns ������������������������������������������������������������������������� 123 Concept ������������������������������������������������������������������������������������������������������������������������ 123 Real-Life Example �������������������������������������������������������������������������������������������������������� 123 Computer World Example ��������������������������������������������������������������������������������������������� 123 Illustration �������������������������������������������������������������������������������������������������������������������� 124 UML Class Diagram ������������������������������������������������������������������������������������������������������ 124 Package Explorer view ������������������������������������������������������������������������������������������������� 125 Implementation ������������������������������������������������������������������������������������������������������������ 125 Output��������������������������������������������������������������������������������������������������������������������������� 127 Note������������������������������������������������������������������������������������������������������������������������������ 128
■Chapter 20: Chain of Responsibility Patterns ���������������������������������������������������� 129 Concept ������������������������������������������������������������������������������������������������������������������������ 129 Real-Life Example �������������������������������������������������������������������������������������������������������� 129 Computer World Example ��������������������������������������������������������������������������������������������� 129 Illustration �������������������������������������������������������������������������������������������������������������������� 130 UML Class Diagram ������������������������������������������������������������������������������������������������������ 130
xiv
Package Explorer view ������������������������������������������������������������������������������������������������� 131 Implementation ������������������������������������������������������������������������������������������������������������ 131 Output��������������������������������������������������������������������������������������������������������������������������� 134 Note������������������������������������������������������������������������������������������������������������������������������ 134
■Chapter 21: Composite Patterns������������������������������������������������������������������������ 135 Concept ������������������������������������������������������������������������������������������������������������������������ 135 Real-Life Example �������������������������������������������������������������������������������������������������������� 135 Computer World Example ��������������������������������������������������������������������������������������������� 135 Illustration �������������������������������������������������������������������������������������������������������������������� 135 UML Class Diagram ������������������������������������������������������������������������������������������������������ 136 Package Explorer view ������������������������������������������������������������������������������������������������� 137 Implementation ������������������������������������������������������������������������������������������������������������ 137 Output��������������������������������������������������������������������������������������������������������������������������� 140 Note������������������������������������������������������������������������������������������������������������������������������ 140
■Chapter 22: Bridge Patterns (Or Handle/Body Patterns) ����������������������������������� 141 Concept ������������������������������������������������������������������������������������������������������������������������ 141 Real-Life Example �������������������������������������������������������������������������������������������������������� 141 Computer World Example ��������������������������������������������������������������������������������������������� 141 Illustration �������������������������������������������������������������������������������������������������������������������� 142 UML Class Diagram ������������������������������������������������������������������������������������������������������ 142 Package Explorer view ������������������������������������������������������������������������������������������������� 143 Implementation ������������������������������������������������������������������������������������������������������������ 143 Output��������������������������������������������������������������������������������������������������������������������������� 146 Note������������������������������������������������������������������������������������������������������������������������������ 146
■ Contents
xv
■ Contents
■Chapter 23: Visitor Patterns ������������������������������������������������������������������������������ 149 Concept ������������������������������������������������������������������������������������������������������������������������ 149 Real-Life Example �������������������������������������������������������������������������������������������������������� 149 Computer World Example ��������������������������������������������������������������������������������������������� 149 Illustration �������������������������������������������������������������������������������������������������������������������� 149 UML Class Diagram ������������������������������������������������������������������������������������������������������ 150 Package Explorer view ������������������������������������������������������������������������������������������������� 151 Implementation ������������������������������������������������������������������������������������������������������������ 151 Output��������������������������������������������������������������������������������������������������������������������������� 153 Note������������������������������������������������������������������������������������������������������������������������������ 153
■Chapter 24: Interpreter Patterns ����������������������������������������������������������������������� 155 Concept ������������������������������������������������������������������������������������������������������������������������ 155 Real–Life Example�������������������������������������������������������������������������������������������������������� 155 Computer World Example ��������������������������������������������������������������������������������������������� 155 Illustration �������������������������������������������������������������������������������������������������������������������� 155 UML Class Diagram ������������������������������������������������������������������������������������������������������ 156 Package Explorer view ������������������������������������������������������������������������������������������������� 157 Implementation ������������������������������������������������������������������������������������������������������������ 158 Output��������������������������������������������������������������������������������������������������������������������������� 161 Note������������������������������������������������������������������������������������������������������������������������������ 161
■Appendix A: FAQ ������������������������������������������������������������������������������������������������ 163 References ������������������������������������������������������������������������������������������������������������������� 164
Index��������������������������������������������������������������������������������������������������������������������� 169
xvi
About the Author
Vaskaran Sarcar, ME (Software Engineering), MCA, B Sc. (Math) is a Senior Software Engineer at Hewlett Packard India Software Operation Pvt. Ltd. He has been working in the HP India PPS R&D Hub since
August 2009. He is an alumnus of prestigious institutions like Jadavpur University, Kolkata, WB, Vidyasagar University, Midnapore, WB and Presidency College, Kolkata, WB, Jodhpur Park Boys School, Kolkata, WB and Ramakrishna Mission Vidyalaya, Narendrapur, Kolkata, WB. He is also the author of the following books: Design Patterns in C#, Operating System: Computer Science Interview Series, C# Basics: Test Your Skill, and Easy Manifestation. He devoted his early years (2005–2007) to teaching in various engineering colleges. Later he received the MHRD-GATE Scholarship (India). Reading and learning new things are passions for him. You can reach him at: vaskaran@rediffmail.com.
xvii
Acknowledgments
I offer sincere thanks to my family, my friends, my great teachers, my publisher and to everyone who supported this project directly or indirectly. Though it is my book, I believe that it was only with the help of these extraordinary people that I was able to complete this work. Again, thanks to those who helped me to fulfill my desire to help people.
xix
Preface
Welcome to the journey. It is my privilege to present Java Design Patterns. Before jumping into the topic, I want to highlight a few points about the topic and contents:
#1. You are an intelligent person. You have chosen a topic that can assist you throughout your career. If you are a developer/programmer, you need these concepts. If you are an architect at a software organization, you need these concepts. If you are a college student, you need these concepts—not only to achieve good grades but also to enter into the corporate world. Even if you are a tester who needs to take care of the white box testing or simply to know about the code paths of the product, these concepts will help you a lot.
#2. This book is written in Java, but the focus is not on the language construct of Java. I has made the examples simple in such a way that if you are familiar with any other popular language (C#, C++, etc.) you can still easily grasp the concept. Except in a few special places, I have made his best effort to follow the naming conventions used in Java.
#3. There are many books on this topic or a related topic. Then why was I interested in adding a new one in the same area? The true and simple answer for this question is: I found that the materials on this topic are scattered. In most cases, many of those examples are unnecessarily big and complex. I always like simple examples. He believes that anyone can grasp an idea with simple examples first. And when the concept is clear, readers are motivated to delve deeper. I believe that this book scores high in this area. The examples used here are simple. I didn’t want to make the book fat, but he did want to make it concise and simple. He wants to grow interest about this topic in your mind—so that, you can also motivate yourself to continue the journey and to dig further with the concepts in your professional fields.
#4. Each of the topics is divided into seven parts—the definition, the core concept, a real-life example, a computer/coding world example, a UML class diagram, a sample program with a high-level view in Package Explorer and output of the program. So, even before you enter into the coding parts, you will be able to form some impression in your mind. These examples are chosen in such a way that you will be able to get back to the core concepts with these examples whenever you need to do so.
#5. Please remember that you have just started the journey. You have to consistently think about these concepts and try to write codes, and only then will you master this area. I was also involved (and am still involved!) in the journey. The sources/references are only a small part of this journey. I went through a large number of materials and ultimately he picked up those which made his concept clearer. So, he is grateful to the authors of those sources because those resources helped him ultimately to clear his doubts and increase his interest in the topic. I am also grateful to his family and friends for their continuous help and support.
#6. Though the patterns described here are broadly classified into three categories—creational, structural, and behavioral—all similar patterns are not grouped together here, so before you start with the examples, concepts, and definition, you can test your understanding—which category is your pattern falling under. Also, you can start with any pattern you like.
#7. No book can be completed without the reader’s feedback and support. So, please share your comments and feedback to truly complete this book and enhance my work in the future.
#8. Always check for the most updated version available in the market. I have decided to highlight the key changes at the beginning of the book. So that you can also update your copy accordingly whenever a new update appears in this book.
—Vaskaran Sarcar xxi
Key Points
#1. We need to know design patterns to find solutions for frequently occurring problems. And we want to reuse these solutions whenever we face a similar situation in the future.
#2. These are one kind of template to address solutions in many different situations.
#3. In other words, these are the descriptions of how different objects and their respective classes solve a design problem in a specific context.
#4. Here we have discussed 23 design patterns as outlined by the Gang of Four. These patterns can be classified into three major categories:
A. Creational Patterns:
These patterns mainly deal with the instantiation process. Here we make the systems independent from how their objects are created, collected, or represented. The following five patterns fall into this category:
Singleton Pattern Abstract Factory Pattern Prototype Pattern Factory Method Pattern Builder Pattern
B. Structural Patterns:
Here we focus on how objects and classes are associated or can be composed to make relatively large structures. Inheritance mechanisms are mostly used to combine interfaces or implementations. The following seven patterns fall into this category:
Proxy Pattern Flyweight Pattern Bridge Pattern Facade Pattern Decorator Pattern Adapter Pattern Composite Pattern
xxiii
■ Key Points
C. Behavioral Patterns:
Here our concentration is on algorithms and the assignment of the critical responsibilities among the objects. We also need to focus on the communication between them. We need to take a closer look at the way those objects are interconnected. The following 11 patterns fall into this category.
Observer Pattern
Template Method Pattern Command Pattern
Iterator Pattern
State Pattern
Mediator Pattern
Strategy Pattern
Chain of Responsibility Pattern Visitor Pattern
Interpreter Pattern
Memento Pattern
#5. Here you can start with any pattern you like. I have chosen the simplest examples for your easy understanding. But you must think of the topic, practice more, try to link with other problems, and then ultimately keep doing the code. This process will help you, ultimately, to master the subject.
xxiv
Chapter 1
Introduction
Over a period of time, software engineers were facing a common problem during the development of various software programs. There were no standards to instruct them how to design and proceed. The issue became significant when a new member (experienced or unexperienced; it does not matter) joined the team and was assigned to do something from scratch or to modify something in the existing product. As already mentioned, since there were no standards, it took a lot of effort to become familiar with the existing product. Design Patterns simply addresses this issue and makes a common platform for all developers. We shall remember that these patterns were intended to be applied in object-oriented designs with the intention of reuse.
In 1994–95, four Is—Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides—published Design Patterns—Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) in which they initiated the concept of design patterns for software development. These Is became known as the Gang of Four (GoF). They introduced 23 patterns which were developed by experienced software engineers over a very long period of time. As a result, now if any new member joins a development team and he knows that the new system is following some specific design patterns, he can actively participate in the development process with the other members of the team within a very short period of time.
The first concept of real-life design pattern came from the building architect Christopher Alexander. In his experience he came to understand some common problems. Then he tried to address those issues with related solutions (for building design) in a uniform manner. People believe that the software industry grasped those concepts because software engineers can also relate their product applications with these building applications.
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
—Christopher Alexander
GoF assures us that though the patterns were described for buildings and towns, the same concepts can be applied for the patterns in object-oriented design. We can substitute the original concepts of walls and doors with objects and interfaces. The common thing in both is that at the core, both types of patterns are solution to problems in some context.
In 1995 the original concepts were discussed with C++. Sun Microsystems released its first public implementation—Java 1.0—in 1995 and then it went through various changes. So, the key point is: Java
was relatively new at that time. In this book, we’ll try to examine these core concepts with Java. The book is written in Java, but still, if you are familiar with any other popular programming languages (C#, C++ etc.), you can also grasp the concept very easily because I has made as his main focus the design patterns and how we can implement the concept with the basic Java language construct. Again: he has chosen simple, easy-to- remember examples to help you to develop these concepts easily.
1
Chapter 2
Observer Patterns
GoF Definition: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
Concept
In this pattern, there are many observers (objects) which are observing a particular subject (object). Observers are basically interested and want to be notified when there is a change made inside that subject. So, they register themselves to that subject. When they lose interest in the subject they simply unregister from the subject. Sometimes this model is also referred to as the Publisher-Subscriber model.
Real-Life Example
We can think about a celebrity who has many fans. Each of these fans wants to get all the latest updates of his/her favorite celebrity. So, he/she can follow the celebrity as long as his/her interest persists. When he loses interest, he simply stops following that celebrity. Here we can think of the fan as an observer and the celebrity as a subject.
Computer World Example
In the world of computer science, consider a simple UI-based example, where this UI is connected with some database (or business logic). A user can execute some query through that UI and after searching the database, the result is reflected back in the UI. In most of the cases we segregate the UI with the database. If a change occurs in the database, the UI should be notified so that it can update its display according to the change.
Illustration
Now let us directly enter into our simple example. Here I have created one observer (though you can create more) and one subject. The subject maintains a list for all of its observers (though here we have only one for simplicity). Our observer here wants to be notified when the flag value changes in the subject. With the output, you will discover that the observer is getting the notifications when the flag value changed to 5 or 25. But there is no notification when the flag value changed to 50 because by this time the observer has unregistered himself from the subject.
3
Chapter 2 ■ Observer patterns UML Class Diagram
4
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package observer.pattern.demo; import java.util.*;
class Observer {
public void update() {
} }
System.out.println(“flag value changed in Subject”);
interface ISubject {
void register(Observer o); void unregister( Observer o); void notifyObservers();
}
class Subject implements ISubject {
List
public int getFlag()
{
return _flag; }
Chapter 2 ■ Observer patterns
5
Chapter 2 ■ Observer patterns
public void setFlag(int _flag) {
this._flag=_flag;
//flag value changed .So notify observer(s)
notifyObservers();
}
@Override
public void register(Observer o) {
observerList.add(o);
}
@Override
public void unregister(Observer o) {
observerList.remove(o);
}
@Override
public void notifyObservers() {
for(int i=0;i
List
And so we need to replace Observer with IObserver in corresponding places also. We have also modified our update function to see the changed values in the Observers themselves.
7
Chapter 2 ■ Observer patterns UML Class Diagram
Package Explorer view
High-level structure of the parts of the modified program is as follows:
8
Implementation
package observer.pattern.demo2; import java.util.*;
interface IObserver {
void update(int i); }
class Observer1 implements IObserver {
@Override
public void update(int i)
{
System.out.println(“Observer1: myValue in Subject is now: “+i); }
}
class Observer2 implements IObserver {
@Override
public void update(int i)
{
} }
interface ISubject {
void register(IObserver o); void unregister(IObserver o); void notifyObservers(int i);
}
class Subject implements ISubject {
private int myValue; public int getMyValue() {
return myValue;
}
public void setMyValue(int myValue) { this.myValue = myValue;
}
System.out.println(“Observer2: observes ->myValue is changed in Subject to :”+i);
//Notify observers
notifyObservers(myValue);
Chapter 2 ■ Observer patterns
9
Chapter 2 ■ Observer patterns
List
@Override
public void register(IObserver o) {
observersList.add(o);
}
@Override
public void unregister(IObserver o) {
observersList.remove(o);
}
@Override
public void notifyObservers(int updatedValue) {
for(int i=0;i
} }
class Observer3 implements IObserver {
@Override
public void update(String s,int i) {
12
} }
interface ISubject {
void register(IObserver o); void unregister(IObserver o); void notifyObservers(int i);
}
class Subject1 implements ISubject {
private int myValue;
System.out.println(“Observer3 is observing:myValue is changed in “+s+” to :”+i);
public int getMyValue() { return myValue;
}
public void setMyValue(int myValue) { this.myValue = myValue;
//Notify observers
notifyObservers(myValue);
}
List
@Override
public void register(IObserver o) {
observersList.add(o);
}
@Override
public void unregister(IObserver o) {
observersList.remove(o);
}
@Override
public void notifyObservers(int updatedValue) {
for(int i=0;i
Chapter 2 ■ Observer patterns
13
Chapter 2 ■ Observer patterns
14
}
@Override
public void register(IObserver o) {
observersList.add(o);
}
@Override
public void unregister(IObserver o) {
observersList.remove(o);
}
@Override
public void notifyObservers(int updatedValue) {
for(int i=0;i
} }
}
// Science.java
public String CurrentItem() {
return subjects[position];
package aggregate;
//for Linked List data structure used here
import java.util.LinkedList; import iterator.*;
public class Science implements ISubject {
private LinkedList
{
subjects = new LinkedList
}
@Override
public IIterator CreateIterator() {
return new ScienceIterator(subjects);
}
//Containing the ScienceIterator
public class ScienceIterator implements IIterator {
private LinkedList
private int position;
public ScienceIterator(LinkedList
this.subjects = subjects; position = 0;
}
public void First() {
}
position = 0;
Chapter 10 ■ Iterator patterns
63
Chapter 10 ■ Iterator patterns
public String Next()
{ }
{ }
{
} }
}
//IteratorPatternEx.java
} }
64
}
return subjects.get(position++); public Boolean IsDone()
return position >= subjects.size(); public String CurrentItem()
package iteratorpattern.demo; import iterator.*;
import aggregate.*;
class IteratorPatternEx {
public static void main(String[] args) {
return subjects.get(position);
System.out.println(“***Iterator Pattern Demo***\n”); ISubject Sc_subject = new Science();
ISubject Ar_subjects = new Arts();
IIterator Sc_iterator = Sc_subject.CreateIterator();
IIterator Ar_iterator = Ar_subjects.CreateIterator();
System.out.println(“\nScience subjects :”); Print(Sc_iterator);
System.out.println(“\nArts subjects :”); Print(Ar_iterator);
public static void Print(IIterator iterator) {
while (!iterator.IsDone()) {
}
System.out.println(iterator.Next());
Output
Chapter 10 ■ Iterator patterns
Note
If you have gone through the above code, probably you now have a fair idea of the power of an iterator and the significance of this pattern. We can support different variations for the traversal of an aggregate (the interface to create an Iterator object), and above all, it simplifies the interface.
But we must be careful while traversing and any kind of modification during that traversal period can cause damage to us. We can take a backup first to deal with this type of scenario, but it is obvious that taking the backup and reexamining it at some later stage is also a costly operation.
65
Chapter 11
Facade Patterns
GoF Definition: Provide a unified interface to a set of interfaces in a system. Facade defines a higher-level interface that makes the subsystem easier to use.
Concept
It is one of those patterns that supports loose coupling. Here we emphasize the abstraction and hide the complex details by exposing a simple interface.
Real-Life Example
Suppose you are going to organize a birthday party and you have invited 100 people. Nowadays, you can go to any party organizer and let him/her know the minimum information— (party type, date and time of the party, number of attendees, etc.). The organizer will do the rest for you. You do not even think about how he/she will decorate the party room, whether people will take food from self-help counter or will be served by a caterer, and so on.
Computer World Example
We can think about a case where we use a method from a library. The user doesn’t care how the method is implemented in the library. He/she just calls the method to serve his/her easy purpose. The pattern can be best described by the example that follows.
Illustration
Here our aim is to build/construct robots. And from a user point of view he/she needs to supply only the color and material for his/her robot through the RobotFacade (See our FacadePatternEx.java file.) Our RobotFacade (RobotFacade.java) will in turn create objects for RobotBody, RobotColor, RobotMetal and will do the rest for the user. We need not worry about the creation of these separate classes and their calling sequence. All of the classes have their corresponding implementation here.
In this example I have followed this structure. Note that the related parts are separated by the packages for better readability.
67
Chapter 11 ■ FaCade patterns UML Class Diagram
Package Explorer view
68
Implementation
//RobotBody.java package robotparts;
public class RobotBody {
public void CreateBody() {
System.out.println(“Body Creation done”);
} }
//RobotColor.java package robotparts;
public class RobotColor {
private String color;
public void SetColor(String color) {
} }
this.color = color;
System.out.println(“Color is set to : “+ this.color);
//RobotMetal.java package robotparts;
public class RobotMetal {
private String metal;
public void SetMetal(String metal) {
} }
this.metal=metal;
System.out.println(“Metal is set to : “+this.metal);
Chapter 11 ■ FaCade patterns
69
Chapter 11 ■ FaCade patterns
//RobotFacade.java package robotfacade; import robotparts.*;
public class RobotFacade {
RobotColor rc; RobotMetal rm ; RobotBody rb;
public RobotFacade() {
rc = new RobotColor(); rm = new RobotMetal(); rb = new RobotBody();
}
public void ConstructRobot(String color,String metal) {
} }
System.out.println(“\nCreation of the Robot Start”); rc.SetColor(color);
rm.SetMetal(metal);
rb.CreateBody();
System.out.println(” \nRobot Creation End”); System.out.println();
//FacadePatternEx.java
package facade.pattern.demo; import robotfacade.RobotFacade;
class FacadePatternEx {
public static void main(String[] args) {
} }
70
System.out.println(“***Facade Pattern Demo***”); RobotFacade rf1 = new RobotFacade(); rf1.ConstructRobot(“Green”, “Iron”);
RobotFacade rf2 = new RobotFacade(); rf2.ConstructRobot(“Blue”, “Steel”);
Output
Chapter 11 ■ FaCade patterns
Note
1. We use Facade pattern to represent a simple interface instead of a complex
subsystem.
2. Here we promote weak coupling among subsystems—so, in this way, we are making them portable.
3. We already mentioned that we separate subsystems from clients by a simple interface. With this model, we not only make the system easier to use but also reduce the number of objects that the clients need to deal with.
4. There is truly no major disadvantage associated with this pattern. On the other hand, it has proven its usefulness in libraries like jQuery also.
71
Chapter 12
Factory Method Patterns
GoF Definition: Define an interface for creating an object, but let subclasses decide which class to instantiate. The factory method lets a class defer instantiation to subclasses.
Concept
The concept can be best described with the examples below.
Real-Life Example
Suppose you have two different types of televisions—one with an LED screen and another with an LCD screen. If any of these starts malfunctioning, you will call a TV repairman to request a visit to your residence. The repairman must ask first what kind of TV is nonoperational. As per your input, he’ll carry the required instruments with him.
Computer World Example
In a Windows application, we may have different database users (e.g., one user uses Oracle and one may use Sql Server). Now whenever we need to insert data in our database we need to create either an SqlConnection or an OracleConnection first; only then we can proceed. If we put them into simple if-else, we need to
repeat lots of codes and it doesn’t look good. We can use the factory pattern to solve these types of problems. The basic structure is defined with an abstract class; our subclasses will be derived from this class. The subclasses will take the responsibility of the instantiation process.
Illustration
Here I have created all classes into a single file. Please go through the code. Note that here we have two animal types—Duck and Tiger. And whenever we try to use a new type, Lion, which was not implemented earlier, an exception will be thrown. If you want to omit this extra part, you can do that. In that case, we also do not need to take precautions for any exceptions.
73
Chapter 12 ■ FaCtory Method patterns UML Class Diagram
Package Explorer view
High-level structure of the parts of the program is as follows:
74
Implementation
package factory.pattern.demo; interface IAnimal
{
void Speak();
}
class Duck implements IAnimal {
@Override
public void Speak() {
System.out.println(“Duck says Pack-pack”);
} }
class Tiger implements IAnimal {
@Override
public void Speak() {
} }
System.out.println(“Tiger says: Halum..Halum”);
abstract class IAnimalFactory {
public abstract IAnimal
/*if we cannot instantiate in later stage, we’ll throw exception*/ GetAnimalType(String type) throws Exception;
}
class ConcreteFactory extends IAnimalFactory {
@Override
public IAnimal GetAnimalType(String type) throws Exception {
switch (type) {
case “Duck”:
return new Duck(); case “Tiger”:
return new Tiger(); default:
}
} }
throw new Exception( “Animal type : “+type+” cannot be instantiated”);
Chapter 12 ■ FaCtory Method patterns
75
Chapter 12 ■ FaCtory Method patterns class FactoryPatternEx
{
{
public static void main(String[] args) throws Exception
System.out.println(“***Factory Pattern Demo***\n”); IAnimalFactory animalFactory = new ConcreteFactory(); IAnimal DuckType=animalFactory.GetAnimalType(“Duck”); DuckType.Speak();
IAnimal TigerType = animalFactory.GetAnimalType(“Tiger”);
TigerType.Speak();
//There is no Lion type. So, an exception will be thrown
IAnimal LionType = animalFactory.GetAnimalType(“Lion”);
LionType.Speak();
} }
Output
If you do not want to see the exception, just do not try to create the Lion type here (i.e., comment out the code).
Note
1. This pattern is useful when our classes shift the responsibilities of objects
creation to its subclasses.
2. This pattern is also useful when implementing parallel class hierarchies (when some of the responsibilities shift from one class to another) and when making a system with loose coupling is possible.
3. One issue that we need to address is that making too many objects often can decrease performance.
76
Chapter 13
Memento Patterns
GoF Definition: Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later.
Concept
Our aim is to save the state of an object, so that in the future, we can go back to the specified state. Three objects are playing the game here—a memento, a caretaker, and the originator. The memento will store the internal states of the originator. The originator can have the internal states and it has the ability to restore into its earlier state. An originator can also retrieve information from the memento. The caretaker takes care of the memento’s safekeeping or protection and it should not examine the contents of the memento.
Real-Life Example
In notepad we use undo frequently by pressing ctrl+Z.
Computer World Example
A classic example in this category includes the state in a finite state machine. Apart from this, in real-world database programming, often we may need to roll back a transaction operation.
Illustration
Please go through the code. Use the comments for your ready reference. Please also note that if you are familiar with C#, you can also use C# properties in place of the getter and setter operations used here.
77
Chapter 13 ■ MeMento patterns UML Class Diagram
78
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package memento.pattern.demo; // Memento class
class Memento {
private String state;
public Memento(String state)
Chapter 13 ■ MeMento patterns
{ }
this.state = state;
79
Chapter 13 ■ MeMento patterns
public String getState()
{
} }
return state;
// Originator class
class Originator {
private String state; Memento m;
public void setState(String state) {
this.state = state;
System.out.println(“State at present : ” +state);
}
// Creates memento
public Memento OriginatorMemento() {
m = new Memento(state);
return m; }
// Back to old state
public void Revert(Memento memento) {
System.out.println(“Restoring to previous state…”); state = memento.getState();
System.out.println(“State at present :” +state);
} }
//Caretaker Class class Caretaker
{
private Memento _memento;
public void SaveMemento(Memento m)
{
_memento = m;
}
public Memento RetrieveMemento() {
} }
80
return _memento;
class MementoPatternEx {
public static void main(String[] args) {
System.out.println(“***Memento Pattern Demo***\n”); Originator o = new Originator();
o.setState(“First state”);
// Holding old state
Caretaker c = new Caretaker(); c.SaveMemento(o.OriginatorMemento());
//Changing state
o.setState(“Second state”);
// Restore saved state
o.Revert(c.RetrieveMemento());
Output
} }
Chapter 13 ■ MeMento patterns
Note
1. We are advised to treat the memento object as an opaque object (i.e., ideally,
caretakers should not be allowed to change them).
2. We should pay special attention so that other objects are not affected by the change made in the originator to the memento.
3. Sometimes, use of this pattern can cost more (e.g., if we want to store and restore large amount of data frequently). Also, from a caretaker point of view, the caretaker has no idea about how much state is kept in the memento that it wants to delete.
81
Chapter 14
State Patterns
GoF Definition: Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Concept
The concept is best described by the examples that follow.
Real-Life Example
Consider a network connection for the moment. Here the object (that is responsible for communication) can be in various states (e.g., already a connection is established, a connection is closed, or the object is listening through the connection). We can also think of a traffic signal in this context.
Computer World Example
The above example is applicable in the computer world also. Let us look at an additional example: We have a job processing application where we can process only one job (or any certain number of jobs) at a time. Now if a new job appears, either the application will process that job or it will signal that the new job cannot be processed at this moment because the system is already processing the maximum number of jobs in it
(i.e., its number of job processing capabilities has reached the ceiling).
Illustration
Here we have picked a very simple switching mechanism for turning a TV on/off. Suppose, we have a remote control to turn the TV on/off. Initially the TV is in the off state. When we press the power button, the TV will be on; upon the next press of the button, the TV will go off. We have implemented this concept with the state design pattern here.
83
Chapter 14 ■ State patternS
UML Class Diagram
84
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package state.pattern.demo; abstract class RemoteControl {
public abstract void pressSwitch(TV context); }
class Off extends RemoteControl {
@Override
public void pressSwitch(TV context){ System.out.println(“I am Off .Going to be On now”); context.setState(new On());
} }
Chapter 14 ■ State patternS
85
Chapter 14 ■ State patternS
class On extends RemoteControl {
@Override
public void pressSwitch(TV context) {
System.out.println(“I am already On .Going to be Off now”); context.setState(new Off());
} }
class TV {
private RemoteControl state; public RemoteControl getState() {
return state;
public void setState(RemoteControl state) {
this.state = state; public TV(RemoteControl state)
} {
}
this.state=state; }
public void pressButton() {
state.pressSwitch(this); }
}
class StatePatternEx
{
{
} }
86
public static void main(String[] args)
System.out.println(“***State Pattern Demo***\n”);
//Initially TV is Off Off initialState = new Off(); TV tv = new TV(initialState);
//First time press
tv.pressButton();
//Second time press
tv.pressButton();
Output
Chapter 14 ■ State patternS
Note
1. As human beings, we perform best when we are happy and free of tension and our behavior can clearly reflect our mental state. It is obvious that when we are in a happy and relaxed mode, we can perform better and we can talk to others in a friendlier tone. But consider the reverse scenario: when we are full of tension. In that scenario, in most cases, our efforts cannot produce a great result. That is why it is always suggested that we should work in relaxed mode. You can relate this simple philosophy with the foregoing illustration. If the TV is on, it can entertain you; if it is off, it cannot—right? So, when we want to design similar kinds of behavior changes of an object when its internal state changes, this pattern becomes handy.
2. If the number of states increases significantly in the system, then it becomes extremely hard to maintain that system.
87
Chapter 15
Builder Patterns
GoF Definition: Separate the construction of a complex object from its representation so that the same construction processes can create different representations.
Concept
The pattern is useful when a creational algorithm of a complex object is independent of the assembly of the parts of the object. The construction process is also capable of building a different representation of that object under consideration.
Real-Life Example
To create a computer, different parts are assembled depending upon the order received by the customer (e.g., a customer can demand a 500 GB hard disk with an Intel processor; another customer can choose a 250 GB hard disk with an AMD processor).
Computer World Example
We sometimes need to convert one text format to another text format (e.g., RTF to ASCII text).
Illustration
Here the participants are IBuilder, Car, MotorCycle, Product, and Director. The first three are very straightforward—Car and MotorCycle are implementing the IBuilder interface. IBuilder is used to create parts of the Product object where Product represents the complex object under construction. The assembly process is described in Product. We can see that we have used the Linked List data structure in Product for this assembly operation.
Car and MotorCycle are the concrete implementations. They have implemented IBuilder interface. That’s why they needed to BuildBody(), InsertWheels(), AddHeadlights(), and finally GetVehicle(). We
use the first three methods to build the body of the vehicle, insert the number of wheels into it, and add headlights to the vehicle. GetVehicle() will return the ultimate product. Finally, Director will be responsible for constructing the ultimate vehicle. Director will build the product with IBuilder interface. He is calling the same Construct() method to create different types of vehicles.
Please go through the code to see how different parts are assembled for this pattern.
89
Chapter 15 ■ Builder patterns UML Class Diagram
90
Package Explorer view
High-level structure of the parts of the program is as follows:
Chapter 15 ■ Builder patterns
91
Chapter 15 ■ Builder patterns Implementation
package builder.pattern.demo; import java.util.LinkedList;
// Builders common interface interface IBuilder
{
void BuildBody(); void InsertWheels(); void AddHeadlights(); Product GetVehicle();
}
// Car is ConcreteBuilder class Car implements IBuilder {
private Product product = new Product();
@Override
public void BuildBody() {
product.Add(“This is a body of a Car”);
}
@Override
public void InsertWheels() {
product.Add(“4 wheels are added”);
}
@Override
public void AddHeadlights() {
product.Add(“2 Headlights are added”);
}
@Override
public Product GetVehicle() {
return product;
} }
// Motorcycle is a ConcreteBuilder class MotorCycle implements IBuilder {
private Product product = new Product(); @Override
92
} }
// “Product” class Product {
public void BuildBody() {
product.Add(“This is a body of a Motorcycle”);
}
@Override
public void InsertWheels() {
product.Add(“2 wheels are added”);
}
@Override
public void AddHeadlights() {
product.Add(“1 Headlights are added”);
}
@Override
public Product GetVehicle() {
}
{
}
//Adding parts
parts.addLast(part);
return product;
// We can use any data structure that you prefer. We have used LinkedList here. private LinkedList
public Product()
{
parts = new LinkedList
public void Show() {
System.out.println(“\n Product completed as below :”); for(int i=0;i
{ }
{
} }
100
return shapes.size();
public IRobot GetRobotFromFactory(String RobotCategory) throws Exception
IRobot robotCategory = null;
if (shapes.containsKey(RobotCategory)) {
robotCategory = shapes.get(RobotCategory);
}
else
{
} }
switch (RobotCategory) {
case “small”:
System.out.println(“We do not have Small Robot. So we are creating a Small Robot now.”);
robotCategory = new SmallRobot();
shapes.put(“small”, robotCategory);
break; case “large”:
System.out.println(“We do not have Large Robot. So we are creating a Large Robot now .”);
robotCategory = new LargeRobot();
shapes.put(“large”, robotCategory);
break; default:
throw new Exception(” Robot Factory can create only small and large shapes”);
return robotCategory;
/**
* @author sarcarv *FlyweightPattern is in action. */
class FlyweightPatternEx {
public static void main(String[] args) throws Exception {
RobotFactory myfactory = new RobotFactory(); System.out.println(“\n***Flyweight Pattern Example***\n”);
IRobot shape = myfactory.GetRobotFromFactory(“small”);
shape.Print();
/*Here we are trying to get the objects additional 2 times. Note that from now onward we do not need to create additional small robots as we have already created this category*/
for (int i = 0; i < 2; i++)
{
shape = myfactory.GetRobotFromFactory("small");
shape.Print();
}
int NumOfDistinctRobots = myfactory.TotalObjectsCreated(); System.out.println("\nDistinct Robot objects created till now= "+ NumOfDistinctRobots);
/*Here we are trying to get the objects 5 times. Note that the second time onward we do not need to create additional large robots as we have already created this category in the first attempt(at i=0)*/
for (int i = 0; i < 5; i++)
} }
{
}
shape = myfactory.GetRobotFromFactory("large");
shape.Print();
NumOfDistinctRobots = myfactory.TotalObjectsCreated(); System.out.println("\n Finally no of Distinct Robot objects created: "+ NumOfDistinctRobots);
Chapter 16 ■ Flyweight patterns
101
Chapter 16 ■ Flyweight patterns Output
Improvement to the program
Now take a closer look to our program. Here it seems that this pattern is behaving similar to a singleton pattern because we cannot create two distinct types of small (or large) robots. But there may be situations where we want different types of small (or large) robots in which the basic structure should be same but it will differ only with some special characteristics. So, we are going to present another example here. This illustration will clear your doubt and you can make the distinction between the flyweight and the singleton patterns.
To make the program simple, we are dealing with robots which can be either king type or queen type. Each of these types can be either green or red. Before making any robot, we’ll consult with our factory. If we already have king or queen types of robots, we’ll not create them again. We will collect the basic structure from our factory and after that we’ll color them. Note that color is extrinsic data here, but the category of robot (king or queen) is intrinsic.
102
UML Class Diagram
Chapter 16 ■ Flyweight patterns
103
Chapter 16 ■ Flyweight patterns Package Explorer view
Implementation
package flyweight.pattern.modified.demo; import java.util.HashMap;
import java.util.Map;
import java.util.Random;
/**
* @author sarcarv * Our interface
*
*/
interface IRobot {
void Print();
}
/**
* @author sarcarv
* A 'ConcreteFlyweight' class-SmallRobot *
*/
104
class Robot implements IRobot {
String robotType;
public String colorOfRobot; public Robot(String robotType) {
this.robotType=robotType;
public void setColor(String colorOfRobot)
{
this.colorOfRobot=colorOfRobot;
}
@Override
public void Print() {
} }
}
System.out.println(" This is a " +robotType+ " type robot with "+colorOfRobot+ "color");
/**
* @author sarcarv
* The 'FlyweightFactory' class *
*/
class RobotFactory {
Map
{ }
{
return shapes.size();
public IRobot GetRobotFromFactory(String robotType) throws Exception
IRobot robotCategory= null;
if (shapes.containsKey(robotType)) {
robotCategory = shapes.get(robotType);
}
else
{
switch (robotType) {
case “King”:
System.out.println(“We do not have King Robot. So we are creating a King Robot now.”);
robotCategory = new Robot(“King”); shapes.put(“King”,robotCategory);
break;
Chapter 16 ■ Flyweight patterns
105
Chapter 16 ■ Flyweight patterns
}
} /**
case “Queen”:
System.out.println(“We do not have Queen Robot. So we are creating a Queen Robot now.”);
robotCategory = new Robot(“Queen”); shapes.put(“Queen”,robotCategory);
break;
default:
throw new Exception(” Robot Factory can create only king and queen type robots”);
} }
return robotCategory;
* @author sarcarv *FlyweightPattern is in action. */
class FlyweightPatternModifiedEx {
public static void main(String[] args) throws Exception {
RobotFactory myfactory = new RobotFactory();
System.out.println(“\n***Flyweight Pattern Example Modified***\n”); Robot shape;
/*Here we are trying to get 3 king type robots*/ for (int i = 0; i < 3; i++)
{
shape =(Robot) myfactory.GetRobotFromFactory("King"); shape.setColor(getRandomColor());
shape.Print();
}
/*Here we are trying to get 3 queen type robots*/ for (int i = 0; i < 3; i++)
{
shape =(Robot) myfactory.GetRobotFromFactory("Queen"); shape.setColor(getRandomColor());
shape.Print();
}
int NumOfDistinctRobots = myfactory.TotalObjectsCreated(); //System.out.println("\nDistinct Robot objects created till now =
"+ NumOfDistinctRobots);
System.out.println("\n Finally no of Distinct Robot objects created: "+ NumOfDistinctRobots);
}
static String getRandomColor() {
Random r=new Random();
/*You can supply any number of your choice in nextInt argument.
106
* we are simply checking the random number generated is an even number
* or an odd number. And based on that we are choosing the color. For
simplicity, we'll use only two colors—red and green
*/
int random=r.nextInt(20); if(random%2==0)
{
return "red"; else
return "green";
Output
} }
} { }
Chapter 16 ■ Flyweight patterns
Note
1. Minimization of storage is one of the key concerns here. If we can have more
flyweights to share, we can save more memory.
2. If we can compute extrinsic states rather than storing them, we can save a significant amount of memory.
3. Sometimes in a tree structure, to share leaf nodes, we combine this pattern with composite pattern.
4. A flyweight interface may or may not enable sharing. In some cases, we may have unshared flyweight objects, which in turn may have concrete flyweight objects as children.
5. In simple terms: intrinsic data make the instance unique, whereas extrinsic data are passed as arguments.
107
Chapter 17
Abstract Factory Patterns
GoF Definition: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Concept
In this pattern, we provide an encapsulation mechanism to a group of individual factories. These factories have a theme in common. In this process, an interface is used to create related objects. Here we do not call their implementer or concrete classes directly. We sometimes refer to this pattern as a factory of factories or a Super factory.
With this pattern, we can interchange the specific implementations without changing the user’s code. But to achieve this, we need to compensate for the complexity of the system. As a result, debugging may be difficult in many scenarios.
Real-Life Example
Suppose we are decorating our room. Now suppose we need two different types of almirah (or, say, table)— one must be made of wood and one of steel. For the wooden almirah, we need to visit a carpenter shop
and for the other type, we can go to a readymade steel almirah shop. Both of these are almirah (or table) factories. Based on our demand, we decide what kind of factory we need. This scenario can be considered an example of this pattern.
Computer World Example
ADO.NET has already implemented similar concepts to establish a connection to a database.
Illustration
In this example, our client is looking for movies and he/she needs to access an Abstract Factory, IMovieFactory, and Abstract Products, ITollywoodMovie and IBollywoodMovie. The client does not care which of these factories is giving the concrete object for him/her. He/she uses only the generic interfaces of their products. The naming conventions are chosen for your easy reference.
109
Chapter 17 ■ abstraCt FaCtory patterns UML Class Diagram
110
Package Explorer view
High-level structure of the parts of the program is as follows:
Chapter 17 ■ abstraCt FaCtory patterns
Implementation
package abstractfactory.pattern.demo; interface ITollywoodMovie
{
String MovieName();
}
interface IBollywoodMovie {
String MovieName();
}
interface IMovieFactory {
ITollywoodMovie GetTollywoodMovie();
IBollywoodMovie GetBollywoodMovie();
}
111
Chapter 17 ■ abstraCt FaCtory patterns
112
//Tollywood Movie collections
class TollywoodActionMovie implements ITollywoodMovie {
@Override
public String MovieName()
{
return "Kranti is a Tollywood Action Movie";
} }
class TollywoodComedyMovie implements ITollywoodMovie {
@Override
public String MovieName() {
return "BasantaBilap is a Tollywood Comedy Movie"; }
}
// Bollywood Movie collections
class BollywoodActionMovie implements IBollywoodMovie
{
@Override
public String MovieName() {
return "Bang Bang is a Bollywood Action Movie"; }
}
class BollywoodComedyMovie implements IBollywoodMovie {
@Override
public String MovieName() {
return "Munna Bhai MBBS is a Bollywood Comedy Movie"; }
}
//Action Movie Factory
class ActionMovieFactory implements IMovieFactory {
public ITollywoodMovie GetTollywoodMovie() {
return new TollywoodActionMovie(); }
public IBollywoodMovie GetBollywoodMovie() {
return new BollywoodActionMovie(); }
}
//Comedy Movie Factory
class ComedyMovieFactory implements IMovieFactory {
public ITollywoodMovie GetTollywoodMovie() {
return new TollywoodComedyMovie(); }
public IBollywoodMovie GetBollywoodMovie() {
return new BollywoodComedyMovie(); }
}
class AbstractFactoryPatternEx {
public static void main(String[] args) {
System.out.println("***Abstract Factory Pattern Demo***");
ActionMovieFactory actionMovies = new ActionMovieFactory(); ITollywoodMovie tAction = actionMovies.GetTollywoodMovie(); IBollywoodMovie bAction = actionMovies.GetBollywoodMovie();
System.out.println("\nAction movies are:"); System.out.println(tAction.MovieName()); System.out.println(bAction.MovieName());
ComedyMovieFactory comedyMovies = new ComedyMovieFactory(); ITollywoodMovie tComedy = comedyMovies.GetTollywoodMovie(); IBollywoodMovie bComedy = comedyMovies.GetBollywoodMovie();
System.out.println("\nComedy movies are:"); System.out.println(tComedy.MovieName()); System.out.println(bComedy.MovieName());
} }
Chapter 17 ■ abstraCt FaCtory patterns
113
Chapter 17 ■ abstraCt FaCtory patterns Output
Note
1. We use this pattern when our system does not care about how its products will be
created or composed.
2. We use this pattern when we need to deal with multiple factories.
3. This pattern separates concrete classes and makes interchanging the products easier. It can also enhance the reliabilities among products. But, at the same time, we must acknowledge the fact that creating a new product is difficult with this pattern (because we need to extend the interface and, as a result, changes will be required in all of the subclasses that already implemented the interface).
114
Chapter 18
Mediator Patterns
GoF Definition: Define an object that encapsulates how a set of objects interacts. The mediator pattern promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.
Concept
A mediator is the one who takes the responsibility of communication among a group of objects. The mediator acts as an intermediary who can track the communication between two objects. The other objects in the system are also aware of this mediator and they know that if they need to communicate among themselves, they need to go through the mediator. The advantage of using such a mediator is that we can reduce the direct interconnections among the objects and thus lower the coupling.
Real-Life Example
In an airplane application, before taking off the flight undergoes a series of checks. These checks confirm that all components/parts (which are dependent on each other) are in perfect condition.
Also, the pilot needs to communicate with the towers at the airport. In general, one pilot from one airline will not communicate with another pilot from a different airline before taking off or landing operations. Towers are acting as the mediator here.
Computer World Example
In a business application, in many cases we need to apply constraints (e.g., suppose we have a form for which we need to supply a user id and then a password for that account). In the same form, we may need
to supply other mandatory information (e-mail id, communication address, age, etc.). Now suppose the functions are implemented as follows: once a user supplies his user id, the form will check whether that user id (supplied by user) is valid. If it is a valid id, then only the password field will be enabled. After supplying these two fields, we may need to check whether the user has provided any e-mail id. Let’s assume here after providing a user id with a valid e-mail and all other mandatory details, our submit button will be enabled (i.e., the overall submit button will be enabled if we supply a valid user id, password, e-mail id, and other mandatory details only). We must also ensure that the user id is an integer, so if the user by mistake provides any character in that field, the submit button still will be in disabled mode. The mediator pattern becomes handy in such a scenario.
115
Chapter 18 ■ Mediator patterns
So, when a program consists of many classes and the logic is distributed among them, it becomes harder to read and maintain. If we need to make some kind of change, it becomes a challenging task for us. The mediator pattern is handy in such a scenario.
Illustration
In the example here, we have a group of three friends—Amit, Sohel, and Raghu. Among these three friends, Raghu is the boss and he needs to coordinate things properly. Amit and Sohel work in Raghu’s team. Whenever Amit and Sohel talk to each other (say, through a chat server), Raghu can see who is sending messages to him (though he does not care about the message). Raghu wants to coordinate things smoothly and whenever he wants to send messages, he wants his messages to reach others instantly. Analyze the code and output and it’ll be clear to you.
UML Class Diagram
116
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package mediator.pattern.demo;
abstract class Mediator {
public abstract void Send(Friend frd, String msg); }
// ConcreteMediator
class ConcreteMediator extends Mediator {
private Friend1 friend1; private Friend2 friend2; private Boss boss;
Chapter 18 ■ Mediator patterns
117
Chapter 18 ■ Mediator patterns
//In this example, setters are sufficient.
public void setFriend1(Friend1 friend1) { this.friend1 = friend1;
}
public void setFriend2(Friend2 friend2) {
this.friend2 = friend2; public void setBoss(Boss boss) {
this.boss = boss;
}
@Override
public void Send(Friend frd,String msg) {
//In all cases, boss is notified if (frd == friend1)
{
friend2.Notify(msg);
boss.Notify(friend1.name + " sends message to " + friend2.name);
}
if(frd==friend2) {
friend1.Notify(msg);
boss.Notify(friend2.name + " sends message to " + friend1.name);
}
//Boss is sending message to others if(frd==boss)
{
friend1.Notify(msg);
friend2.Notify(msg);
}
} }
// Friend
abstract class Friend {
protected Mediator mediator; public String name;
118
}
// Constructor
public Friend(Mediator _mediator) {
mediator = _mediator;
}
}
// Friend1—first participant class Friend1 extends Friend {
public Friend1(Mediator mediator,String name) {
super(mediator); this.name = name;
}
public void Send(String msg) {
mediator.Send(this,msg); }
public void Notify(String msg) {
System.out.println("Amit gets message: "+ msg);
} }
// Friend2—Second participant class Friend2 extends Friend {
// Constructor
public Friend2(Mediator mediator,String name) {
super(mediator); this.name = name;
}
public void Send(String msg) {
mediator.Send(this,msg); }
public void Notify(String msg) {
} }
System.out.println("Sohel gets message: "+ msg);
Chapter 18 ■ Mediator patterns
119
Chapter 18 ■ Mediator patterns
120
// Friend3—Third participant. He is the boss. He is notified whenever friend1 and friend2 communicate.
class Boss extends Friend
{
// Constructor
public Boss(Mediator mediator,String name) {
super(mediator); this.name = name;
}
public void Send(String msg) {
mediator.Send(this, msg); }
public void Notify(String msg) {
System.out.println("\nBoss sees message: " + msg); System.out.println("");
} }
class MediatorPatternEx {
public static void main(String[] args) {
System.out.println("***Mediator Pattern Demo***\n"); ConcreteMediator m = new ConcreteMediator();
Friend1 Amit= new Friend1(m,"Amit"); Friend2 Sohel = new Friend2(m,"Sohel"); Boss Raghu = new Boss(m,"Raghu");
m.setFriend1(Amit);
m.setFriend2(Sohel);
m.setBoss(Raghu);
Amit.Send("[Amit here]Good Morrning. Can we discuss the mediator pattern?");
Sohel.Send("[Sohel here]Good Morning.Yes, we can discuss now.");
Raghu.Send("\n[Raghu here]:Please get back to work quickly");
} }
Output
Chapter 18 ■ Mediator patterns
Note
1. Now you should have a clear idea that this pattern is very useful when we observe complex communications in the system. Communication (among objects) is much simpler with this pattern.
2. This pattern reduces the number of subclasses in the system and it also enhances the loose coupling in the system.
3. Here the “many-to-many” relationship is replaced with the “one-to-many” relationship—which is much easier to read and understand.
4. We can provide a centralized control with this pattern.
5. Sometimes the encapsulation process becomes tricky and we find it difficult to maintain or implement.
121
Chapter 19
Prototype Patterns
GoF Definition: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Concept
The prototype pattern provides an alternative method for instantiating new objects by copying or cloning an instance of an existing one. Creating a new instance, in a real-world scenario, is normally treated as an expensive operation. This pattern helps us to deal with this issue. Our focus here is to reduce the expense of this creational process of a new instance.
Real-Life Example
Suppose we have a master copy of a valuable document. We want to make some change to it to get a different feel. We can make a photocopy of this document and then try to edit our changes.
Computer World Example
Suppose we have made an application. The next time we want to create a similar application with some small changes, we must start with a copy from our master copy application and make the changes. We’ll not start from the scratch.
123
Chapter 19 ■ prototype patterns Illustration
In my example, I am going to follow the structure shown here:
Here BasicCar is our prototype. Nano and Ford are our Concrete Prototypes and they need to implement the Clone() method defined in BasicCar. Here we notice that a BasicCar model is created with some default price. Later we have modified that price as per the model. Please also note that PrototypePatternEx is the client here. As usual, the related parts are separated by the packages for better readability.
UML Class Diagram
124
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
//BasicCar.java
package car;
import java.util.Random;
public abstract class BasicCar implements Cloneable {
public String modelname; public int price;
public String getModelname() {
return modelname; }
public void setModelname(String modelname) {
this.modelname = modelname; }
public static int setPrice() {
int price = 0;
Random r = new Random(); int p = r.nextInt(100000); price = p;
return price; }
Chapter 19 ■ prototype patterns
125
Chapter 19 ■ prototype patterns
public BasicCar clone() throws CloneNotSupportedException
{
}
} //Ford.java package car;
return (BasicCar)super.clone();
public class Ford extends BasicCar {
public Ford(String m) {
modelname = m;
}
@Override
public BasicCar clone() throws CloneNotSupportedException {
} }
//Nano.java package car;
return (Ford)super.clone();
public class Nano extends BasicCar {
public Nano(String m) {
modelname = m;
}
@Override
public BasicCar clone() throws CloneNotSupportedException {
return (Nano)super.clone();
} }
//PrototypePatternEx.java package prototype.pattern.demo; import car.*;
public class PrototypePatternEx {
public static void main(String[] args) throws CloneNotSupportedException {
System.out.println("***Prototype Pattern Demo***\n"); BasicCar nano_base = new Nano("Green Nano");
nano_base.price=100000;
126
} }
Output
BasicCar ford_basic = new Ford("Ford Yellow"); ford_basic.price=500000;
BasicCar bc1;
//Clone Nano Object
bc1 =nano_base.clone();
//Price will be more than 100000 for sure
bc1.price = nano_base.price+BasicCar.setPrice();
System.out.println("Car is: "+ bc1.modelname+" and it's price is Rs."+bc1.price);
//Clone Ford Object
bc1 =ford_basic.clone();
//Price will be more than 500000 for sure
bc1.price = ford_basic.price+BasicCar.setPrice();
System.out.println("Car is: "+ bc1.modelname+" and it's price is Rs."+bc1.price);
Chapter 19 ■ prototype patterns
127
Chapter 19 ■ prototype patterns Note
1. When the system does not care about the creational mechanism of the products, this pattern is very helpful.
2. We can use this pattern when we need to instantiate classes at runtime.
3. In our example, we have used the default clone() method in Java, which is a
shallow copy. Thus, it is inexpensive compared to a deep copy.
What are the advantages of the prototype pattern?
1. We can include or discard products at runtime.
2. We can create new instances with a cheaper cost.
What are the disadvantages of the prototype pattern?
1. Each subclass has to implement the cloning mechanism.
2. Implementing the cloning mechanism can be challenging if the objects under consideration do not support copying or if there is any kind of circular reference.
128
Chapter 20
Chain of Responsibility Patterns
GoF Definition: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
Concept
Here we process a series of objects one by one (i.e., in a sequential manner). A source will initiate this processing. With this pattern, we constitute a chain where each of the processing objects can have some logic to handle a particular type of command object. After one’s processing is done, if anything is still pending, it can be forwarded to the next object in the chain. We can add new objects anytime at the end of a chain.
Real-Life Example
In an organization, there are some customer care executives who handle feedback/issues from customers and forward those customer issues/escalations to the appropriate department in the organization. Not all departments will start fixing an issue. The department that seems to be responsible will take a look first, and if the department staff believe that the issue should be forwarded to another department, he/she will do that.
Computer World Example
Consider an application which is handling e-mail and faxes. As usual, we need to take care of the issues reported in each of these communications. We need to introduce two error handlers—EmailErrorHandler and FaxErrorHandler. EmailErrorHandler will handle e-mail errors only and is not responsible for fax errors. In the same manner, FaxErrorHandler will handle fax errors and does not care about e-mail errors.
Then we can make a chain as follows: whenever our main application finds an error, it will just raise this and forward the error with the hope that one of those handlers will handle it. The request will first come to FaxErrorhandler—if it finds that it is a fax issue, it’ll handle the request; otherwise, it will forward the issue to EmailErrorHandler.
Note that here our chain ends with EmailErrorHandler. But if we need to handle another type of issue (e.g., Authentication), we can make an AuthenticationErrorHandler and put it after EmailErrorHandler. So, now, whenever the issue cannot be fixed by EmailErrorHandler, the issue can be forwarded to AuthenticationErrorHandler and the chain will end there.
Thus, the bottom line is as follows: the chain will end if the issue is being processed by some handler or there are no more handlers to process it (i.e., we have reached the end of the chain).
129
Chapter 20 ■ Chain of responsibility patterns Illustration
In this example, we are processing both normal and high-priority issues from e-mail and fax communications.
UML Class Diagram
130
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package chainofresponsibility.pattern.demo; enum MessagePriority
{
Normal,
High
}
class Message {
public String Text;
public MessagePriority Priority;
public Message(String msg, MessagePriority p)
Chapter 20 ■ Chain of responsibility patterns
131
Chapter 20 ■ Chain of responsibility patterns {
Text = msg; this.Priority = p;
} }
interface IReceiver {
Boolean ProcessMessage(Message msg);
}
Class IssueRaiser {
public IReceiver setFirstReceiver;
public IssueRaiser(IReceiver firstReceiver) {
this.setFirstReceiver = firstReceiver; public void RaiseMessage(Message msg)
if (setFirstReceiver != null) setFirstReceiver.ProcessMessage(msg);
} }
class FaxErrorHandler implements IReceiver {
private IReceiver _nextReceiver;
public FaxErrorHandler(IReceiver nextReceiver) {
_nextReceiver = nextReceiver;
}
public Boolean ProcessMessage(Message msg) {
if (msg.Text.contains("Fax")) {
System.out.println("FaxErrorHandler processed "+ msg.Priority+ "priority issue: "+ msg.Text);
return true;
}
else
{
} }
132
} {
}
return false;
if (_nextReceiver != null) _nextReceiver.ProcessMessage(msg);
class EmailErrorHandler implements IReceiver {
private IReceiver _nextReceiver;
public EmailErrorHandler(IReceiver nextReceiver) {
_nextReceiver = nextReceiver;
}
public Boolean ProcessMessage(Message msg) {
if (msg.Text.contains("Email")) {
System.out.println("EmailErrorHandler processed "+ msg.Priority+ "priority issue: "+ msg.Text);
return true;
else
{ }
return false;
class ChainOfResponsibilityPatternEx
} }
{
{
} }
}
if (_nextReceiver != null) _nextReceiver.ProcessMessage(msg);
public static void main(String[] args)
System.out.println("***Chain of Responsibility Pattern Demo***\n"); //Making the chain first: IssueRaiser->FaxErrorhandler->EmailErrorHandler IReceiver faxHandler, emailHandler;
//end of chain
emailHandler = new EmailErrorHandler(null);
//fax handler is before email
faxHandler = new FaxErrorHandler(emailHandler);
//starting point: raiser will raise issues and set the first handler IssueRaiser raiser = new IssueRaiser (faxHandler);
Message m1 = new Message(“Fax is reaching late to the destination”, MessagePriority.Normal);
Message m2 = new Message(“Email is not going”, MessagePriority.High); Message m3 = new Message(“In Email, BCC field is disabled occasionally”, MessagePriority.Normal);
Message m4 = new Message(“Fax is not reaching destination”, MessagePriority.High);
raiser.RaiseMessage(m1);
raiser.RaiseMessage(m2);
raiser.RaiseMessage(m3);
raiser.RaiseMessage(m4);
Chapter 20 ■ Chain of responsibility patterns
133
Chapter 20 ■ Chain of responsibility patterns Output
Note
1. This pattern is used when we issue a request without specifying the receiver. We
expect any of our receivers to handle that request.
2. There may be situation in which more than one receiver can handle the request but the receivers do not know the priority. However, we want to handle the request by the receiver based on the priority. This pattern can help us to design such a scenario.
3. We may need to have the capability to specify objects (that can handle a request) in runtime.
4. We can either define a new link or use an existing link when we need to implement a successor chain.
5. Sometimes we can try to implement an automatic mechanism for forwarding
a request. The advantage is that we can avoid implementing a specific forwarding mechanism from one point to another point in our chain. Smalltalk’s doesnotUnderstand is a typical example in this context.
134
Chapter 21
Composite Patterns
GoF Definition: Compose objects into tree structures to represent part-whole hierarchies. The composite pattern lets clients treat individual objects and compositions of objects uniformly.
Concept
This pattern can show part-whole hierarchy among objects. A client can treat a composite object just like a single object. In object-oriented programming, we make a composite object when we have many objects with common functionalities. This relationship is also termed a “has-a” relationship among objects.
Real-Life Example
We can think of any organization that has many departments, and in turn each department has many employees to serve. Please note that actually all are employees of the organization. Groupings of employees create a department, and those departments ultimately can be grouped together to build the whole organization.
Computer World Example
Any tree structure in computer science can follow a similar concept.
Illustration
In this example we are showing a college organization. We have a Principal and two Heads of Departments: one for computer science and one for mathematics. At present, in the mathematics department, we have two lecturers; in the computer science department we have three lecturers. At the end, one lecturer from the computer science department retires/leaves. We have represented the scenario with the following simple example.
135
Chapter 21 ■ Composite patterns UML Class Diagram
136
Package Explorer view
High-level structure of the parts of the program is as follows:
Implementation
package composite.pattern.demo; import java.util.*;
interface ITeacher
{
public String getDetails(); class Teacher implements ITeacher
private String teacherName; private String deptName;
private List
Teacher(String teacherName, String deptName)
{
this.teacherName = teacherName; this.deptName = deptName;
controls = new ArrayList
}
public void Add(Teacher teacher) {
} {
}
controls.add(teacher);
Chapter 21 ■ Composite patterns
137
Chapter 21 ■ Composite patterns
public void Remove(Teacher teacher)
{
controls.remove(teacher);
}
public List
return controls;
}
@Override
public String getDetails() {
return (teacherName + ” is the ” + deptName);
}
}
class CompositePatternEx {
public static void main(String[] args) {
Teacher Principal = new Teacher(“Dr.S.Som”,”Principal”);
Teacher hodMaths = new Teacher(“Mrs.S.Das”,”Hod-Math”);
Teacher hodCompSc = new Teacher(“Mr. V.Sarcar”,”Hod-ComputerSc.”);
Teacher mathTeacher1 = new Teacher(“Math Teacher-1″,”MathsTeacher”); Teacher mathTeacher2 = new Teacher(“Math Teacher-2″,”MathsTeacher”);
Teacher cseTeacher1 = new Teacher(“CSE Teacher-1″,”CSETeacher”); Teacher cseTeacher2 = new Teacher(“CSE Teacher-2″,”CSETeacher”); Teacher cseTeacher3 = new Teacher(“CSE Teacher-3″,”CSETeacher”);
//Principal is on top of college
/*HOD -Maths and Comp. Sc. directly reports to him*/
Principal.Add(hodMaths);
Principal.Add(hodCompSc);
/*Teachers of Mathematics directly reports to HOD-Maths*/
hodMaths.Add(mathTeacher1);
hodMaths.Add(mathTeacher2);
/*Teachers of Computer Sc. directly reports to HOD-Comp.Sc.*/
hodCompSc.Add(cseTeacher1);
hodCompSc.Add(cseTeacher2);
hodCompSc.Add(cseTeacher3);
/*Leaf nodes. There is no department under Mathematics*/ mathTeacher1.Add(null);
mathTeacher2.Add(null);
138
}
} }
/*Leaf nodes. There is no department under CSE.*/ cseTeacher1.Add(null);
cseTeacher2.Add(null);
cseTeacher3.Add(null);
//Printing the details
System.out.println(“***COMPOSITE PATTERN DEMO ***”); System.out.println(“\nThe college has following structure\n”); System.out.println(Principal.getDetails());
List
for(int i=0;i