0% found this document useful (0 votes)
76 views15 pages

Brief Overview of Gof Design Patterns: Appendix A

Uploaded by

Marat Tynarbekov
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views15 pages

Brief Overview of Gof Design Patterns: Appendix A

Uploaded by

Marat Tynarbekov
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

APPENDIX A

 rief Overview of GoF


B
Design Patterns
We all have unique thought processes. So, in the early days of software development,
engineers faced a common problem—there was no standard to instruct them how
to design their applications. Each team followed their own style, and when a new
member (experienced or unexperienced) joined an existing team, understanding the
architecture was a gigantic task. Senior or experienced members of the team would
need to explain the advantages of the existing architecture and why alternative designs
were not considered. The experienced developer also would know how to reduce future
efforts by simply reusing the concepts already in place. Design patterns address this kind
of issue and provide a common platform for all developers. You can think of them as
the recorded experience of experts in the field. Patterns were intended to be applied in
object-oriented designs with the intention of reuse.
In 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published
the book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-­
Wesley, 1994). In this book, they introduced the concept of design patterns in software
development. These authors became known as the Gang of Four. We will refer them
as the GoF throughout this book. The GoF described 23 patterns that were developed
by the common experiences of software developers over a period of time. Nowadays,
when a new member joins a development team, the developer first learns about the
design patterns of the existing system. Then the developer learns about the existing
architecture. This allows the developer to actively participate in the development
process within a short period of time.

439
© Vaskaran Sarcar 2018
V. Sarcar, Design Patterns in C#, https://doi.org/10.1007/978-1-4842-3640-6
Appendix A Brief Overview of GoF Design Patterns

The first concept of a real-life design pattern came from the building architect
Christopher Alexander. During his lifetime, he discovered that many of the problems
he faced were similar in nature. So, he tried to address those issues with similar types of
solutions.

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

The GoF assured us that though these patterns were described for buildings and towns,
the same concepts can be applied to patterns in object-oriented design. We can substitute
the original concepts of walls and doors with objects and interfaces. The common thing in
both fields is that, at their cores, patterns are solutions to common problems.
The GoF discussed the original concepts in the context of C++. C# 1.0 was released
in 2002, and at the time of this writing, C# 7.0 is available with Visual Studio 2017. In this
book, I’ll examine the GoF’s original design patterns but with C#. The book is written in
C#, but if you are familiar with any other popular programming languages such as Java,
C++, and so on, you will be able to relate because I focus on the design patterns and not
on the latest features of C#. In fact, I have purposely chosen simple examples to help you
to understand these concepts easily.

Key Points
The following are key points about design patterns:

• A design pattern is a general, reusable solution for commonly


occurring problems. The basic idea is that you can solve similar
kinds of problems with similar kinds of solutions. In addition, these
solutions have been tested over a long period of time.

• Patterns generally provide a template of how to solve a problem and


can be used in many different situations. At the same time, they help
you to achieve the best possible design much faster.

440
Appendix A Brief Overview of GoF Design Patterns

• Patterns are descriptions of how to create objects and classes


and then customize them to solve a general design problem in a
particular context.

• The GoF discussed 23 design patterns. Each of these patterns focuses


on a particular object-oriented design. Each pattern can also describe
the consequences and trade-offs of use. The GoF categorized these 23
patterns based on their purposes, as shown here:
A. Creational patterns

These patterns abstract the instantiation process. You


make the systems independent from how their objects are
composed, created, and represented. The following five
patterns are this category:

Singleton pattern
Prototype pattern
Factory Method pattern
Builder pattern
Abstract Factory pattern

B. Structural patterns

This category focuses on how classes and objects can be


composed to form relatively large structures. They generally
use inheritance to compose interfaces or implementations.
The following seven patterns fall into this category:
Proxy pattern
Flyweight pattern
Composite pattern
Bridge pattern
Facade pattern
Decorator pattern
Adapter pattern

441
Appendix A Brief Overview of GoF Design Patterns

C. Behavioral patterns

Here the concentration is on algorithms and the assignment


of responsibilities among objects. You also need to focus
on the communication between them and how the objects
are interconnected. The following 11 patterns fall into this
category:

Observer pattern

Strategy pattern

Template Method pattern

Command pattern

Iterator pattern

Memento pattern

State pattern

Mediator pattern

Chain of Responsibility pattern

Visitor pattern

Interpreter pattern

The GoF made another classification based on scope, namely,


whether the pattern primary focuses on the classes or its objects.
Class patterns deal with classes and subclasses. They use
inheritance mechanisms, which are static and fixed at compile
time. Object patterns deal with objects that can change at run
time. So, object patterns are dynamic.

442
Appendix A Brief Overview of GoF Design Patterns

For a quick reference, you can refer to the following table that was
introduced by the GoF:

• In this book, you can start with any pattern you like. I have chosen
simple examples so that you can pick up the basic ideas quickly. Read
about each pattern, practice, try to solve other problems with the
these patterns, and then just keep coding. This process will help you
to master the subject quickly.

Q&A Session
1. What are differences between class patterns and object patterns?

In general, class patterns focus on static relationship, and object


patterns can focus on dynamic relationships. As the names suggest,
class patterns focus on classes and their subclasses, and object
patterns focus on the object relationships.

443
Appendix A Brief Overview of GoF Design Patterns

The GoF further differentiated them as follows:

Class Patterns Object Patterns

Creational Can defer object creation to subclasses Can defer object creation to another
object
Structural Focuses on the composition of classes Focuses on the different ways of
(primarily uses the concept of inheritance) composition of objects
Behavioral Describes the algorithms and execution Describes how different objects can
flows work together and complete a task

2. Can two or more patterns be combined in an application?

Yes. In real-world scenarios, this type of activity is common.

3. Do these patterns depend on a particular programming


language?

Programming languages can play an important role in pattern use.


But the basic ideas are the same; patterns are just like templates,
and they will give you some idea in advance of how you can solve a
particular problem. In this book, I primarily focus on object-oriented
programming with the concept of reuse. But instead of an object-­
oriented programming language, suppose you have chosen some
other language like C. In that case, you may need to think about the
core object-oriented principles such as inheritance, polymorphism,
encapsulation, abstraction, and so on, and how to implement them.
So, the choice of a particular language is always important because it
may have some specialized features that can make your life easier.

4. Should we consider common data structures such as arrays


and linked lists as design patterns?

The GoF clearly excludes these concepts, saying that they are not
complex, domain-­specific designs for an entire application or
subsystem. They can be encoded in classes and reused as is. So, they
are not your concern in this book.

444
APPENDIX B

Some Useful Resources


This appendix lists some useful resources. The following are helpful books:
• Design Patterns: Elements of Reusable Object-Oriented Software by
Erich Gamma et al. (Addison-Wesley, 1995)
• Head First Design Patterns by Eric Freeman and Elisabeth Robson
(O’Reilly, 2004)
• Java Design Patterns by Vaskaran Sarcar (Apress, 2015)
• Design Patterns For Dummies by Steve Holzner
(Wiley Publishing, Inc, 2006)
• Design Patterns in C# by Jean Paul (Kindle edition, 2012)

The following are helpful online resources/websites:


• www.dofactory.com
• www.c-sharpcorner.com
• www.dotnet-tricks.com/
• www.codeproject.com/
• http://sourcemaking.com/design_patterns
• https://en.wikipedia.org
• https://www.youtube.com/watch?v=ffQZIGTTM48&list=PL8C53D99
ABAD3F4C8
• www.tutorialspoint.com/design_pattern
• www.dotnetexamples.com/
• https://java.dzone.com/
• https://msdn.microsoft.com/
445
© Vaskaran Sarcar 2018
V. Sarcar, Design Patterns in C#, https://doi.org/10.1007/978-1-4842-3640-6
APPENDIX C

The Road Ahead


Congratulations! You have reached the end of our journey together. I believe you
have enjoyed your learning experience, and this experience can help you to learn and
experiment further in this category. I said earlier that if you repeatedly think about the
discussions, examples, implementations, and questions and answers discussed in the
book, you will have more clarity about them, you will feel more confident about them,
and you will remake yourself in the programming world.
A detailed discussion of any particular design pattern would need many more pages,
and the size of the book would be too gigantic to digest. So, what is next? You should not
forget the basic principle that learning is a continuous process. This book was an attempt
to encourage you to learn the core concepts in depth so that you can continue learning.
Still, learning by yourself will not be enough. I suggest you participate in open
forums and discussions to get more clarity on the subjects in this book. This process will
not only help you, it will help others also.
Lastly, I have a request: criticism is allowed, but please also let me know what you
liked about this book. In general, an artistic view and open mind are required to discover
the true efforts that are associated with any kind of work. Thank you and happy coding!

447
© Vaskaran Sarcar 2018
V. Sarcar, Design Patterns in C#, https://doi.org/10.1007/978-1-4842-3640-6
Index
A object, 109
Output, 103
Abstract Factory pattern
Solution Explorer
Class Diagram, 58
View, 100–101
concept, 55
user interface and
GoF definition, 55
database, 98
illustration, 57
Anti-patterns
implementation, 60–63
catalog, 394
Output, 63
causes, 393
PetAnimalFactory, 57
concepts, 394
real-life example, 56
definition, 391
Solution Explorer View, 58–59
refactoring, 395
structure, 56, 57
software developers, 392
WildAnimalFactory, 57
symptoms, 393
Adapter pattern
class, 110
Class Diagram, 99 B
concept, 97 Bridge pattern
Directed Graph advantages, 164
Document, 100 challenges, 164
drawbacks, 111 Class Diagram, 157–158
electrical outlet, 97–98 concept, 155
GetArea() method, 99 electronic items, 156–157
GoF definition, 97 GoF definition, 155
implementation, 102–103 GUI frameworks, 156
modified illustration implementation, 159–162
characteristics, 104 Output, 163
implementation, 106–108 simple subclassing, 164
Output, 109 Solution Explorer View, 159
Solution Explorer View, 105 State pattern, 163

449
© Vaskaran Sarcar 2018
V. Sarcar, Design Patterns in C#, https://doi.org/10.1007/978-1-4842-3640-6
Index

Builder pattern Class Diagram, 225


Class Diagram, 33 concept, 223
concept, 31 Directed Graph Document, 226
ConcreteBuilder objects, 32 GoF definition, 223
converting RTF to ASCII, 32 implementation, 228–230
GoF definition, 31 vs. Interpreter pattern, 434
IBuilder interface, 32 invocation process, 223
implementation, 34–38 invoker, 241
Output, 39 vs. Memento pattern, 433
real-life example, 32 modified Class
Solution Explorer View, 33–34 Diagram, 232
vs. Strategy pattern, 434 modified
implementation, 234–239
Modified Output, 240
C Output, 231
Chain of Responsibility pattern painting, 223
advantages, 313 receivers, 231
AuthenticationErrorHandler, 305 Solution Explorer
challenges, 313 View, 227, 233
Class Diagram, 306 WPF, 224
concept, 303 Common Language
customer care representatives, 304 Runtime (CLR), 398
vs. Decorator pattern, 434 Composite pattern
Directed Graph Document, 307 abstract class, 154
EmailErrorHandler and advantages, 152
FaxErrorHandler, 304–305 challenges, 153
GoF definition, 303 Class Diagram, 146
implementation, 308, 310–311 college organization, 144–145
message priorities, 312 concept, 143
vs. Observer pattern, 314, 434 data structure, 153
Output, 312 GoF definition, 143
request-handling mechanism, 303 implementation, 148–150
software application, 304 iterator design pattern, 153
Solution Explorer View, 307–308 object-oriented
Class adapters, 110 programming, 143
Command pattern organization and
advantages, 242 employees, 144
challenges, 242 Output, 151

450
Index

Solution Explorer View, 147 GoF definition, 113


tree data structure, 144 implementation, 116–119
Criticisms, 385–387 loose coupling, 113
Output, 120–121
D, E Solution Explorer View, 115
subsystems, 121–122
Decorator pattern
Factory Method pattern
abstract method, 94
analysis, 51
advantages, 91
Class Diagram, 44
Class Diagram, 86
concept, 43
component, 85
database users, 44
concept, 83
Directed Graph Document, 45
disadvantages, 94
GoF definition, 43
dynamic behavior, 91
IAnimalFactory class, 49
dynamic binding, 96
implementation, 46, 48
functionality, 83
Output, 49, 51
GoF definition, 83
Solution Explorer
GUI-based toolkit, 85
View, 45–46
implementation, 88–89
Flyweight pattern
inheritance mechanism, 92–93
advantages, 140
original house, 83–84
business cards, 124
Output, 90
challenges, 141
polymorphism, 95
Class Diagram, 125
single responsibility, 93
computer game, 124
Solution Explorer View, 87
concept, 123
GoF definition, 123
F implementation, 127–130
Facade pattern improvements, 131
vs. Adapter pattern, 122 modified Class Diagram, 132
advantages, 121 modified implementation, 133–137
birthday party, 113 Modified Output, 137–138
vs. Builder pattern, 433 multithreading, 140
challenges, 122 nonshareable, 141
Class Diagram, 114 Output, 130
concept, 113 vs. Singleton pattern, 138, 140
ConstructMilanoRobot and small and large robots, 124
DestroyMilanoRobot, 114 Solution Explorer View, 127, 133
Directed Graph Document, 115 vs. State pattern, 436

451
Index

G, H concept, 315
GoF definition, 315
Garbage collection (GC)
grammar rules, 316
allocated objects, 400
implementation, 318–325
automatic memory management, 412
Java compiler, 315
characteristics, 404
Output, 325
coding
Solution Explorer View, 318
comment lines, 417
translator, foreign language, 315
compile, 413, 415
Iterator pattern
destructor method, 417
challenges, 254
developer command
Class Diagram, 245
prompt, 417–418
collection objects, 243, 254
invoking Dispose(), 418
concept, 243
prediction, output, 415–416
data structure, student records, 244
Common Language Runtime (CLR), 398
Directed Graph Document, 246
compaction, 406
First(), Next(), IsDone(), and
destructors, 399, 405
CurrentItem() methods, 244
dirty objects, 397
GoF definition, 243
Dispose() method, 409–411
implementation, 248–255
Finalize() method, 405
Output, 253
finalizers, drawbacks, 412
Solution Explorer View, 247
GC.Collect(), 407
GC.SuppressFinalize(this), 411
IDisposable interface, 408–409 M
implementation, 400–403
Mediator pattern
longer-lived objects, 398
advantages, 300–301
low-priority thread, 397
airplanes, 283
managed heap, 405
analysis, 292
memory consumption rate, 400
Class Diagram, 286
Output, 403
concept, 283
short-lived objects, 398
disadvantages, 301
System.GC.Collect() method, 400
vs. Facade pattern, 301, 436
GoF definition, 283
I, J, K, L implementation, 288–292
Interpreter pattern interconnections, objects, 301
advantages, 326 modified implementation, 294–299
challenges, 326 Modified Output, 299–300
Class Diagram, 316–317 vs. Observer pattern, 435

452
Index

Output, 292 Model-view-controller (MVC) pattern


participants, 285 advantages, 378
registered participants, 293–294 architecture, variations, 356–358
Solution Explorer View, 286–287 challenges, 378
Memento pattern Class Diagram, 362
advantages, 267 components, 355–356
ArrayList, 266 definition, 355
challenges, 267 implementation, 363–372
Class Diagram, 258 Output, 373–377, 380–381
concept, 257 restaurant, 359
Directed Graph Document, 259 Solution Explorer View, 360, 362–363
drawing application, 257 web programming frameworks, 359
GoF definition, 257 Windows Forms application, 360–361
implementation, 260–263
mathematical model, 257 N
memento, originator, and caretaker, 258
Null Object pattern
modified implementation, 264–265
analysis, unwanted input, 344
Modified Output, 266
challenges, 354
operations, 268
Class Diagram, 347
Output, 264
concept, 341
Solution Explorer View, 260
definition, 341
Memory leaks, 397
faulty program, 342–343
causes, 430–431
if/else blocks, 346
CLR profiler, 430
immediate remedy, 345
demonstration code, 420–421
implementation, 349–351
Diagnostic Tools, 420, 422
Output, 352–353
heap view, snapshots, 423, 428
Output with valid inputs, 344
leaking rate, 397, 419
runtime exception, 345
IL code of Main() method, 429
Solution Explorer View, 348
modified code, 424–425
vehicles, 346
modified results, 427
washing machine, 346
objects, 423
online application, 419
symptoms, 432 O
System.OutOfMemoryException, 419 Object adapters, 109
tools, 420 Observer pattern
try/finally blocks, 429–430 benefits, 198
using statement, 428–430 Chain of Responsibility, 196

453
Index

Observer pattern (cont.) Modified Output, 82


challenges, 198 Output, 76
Class Diagram, 189 real-life example, 71
concept, 185 Solution Explorer View, 73–74
GoF definition, 185
implementation, 191–194
notifications, 189, 196 S
notifications from subject, 185–188 Simple Factory pattern
one-to-many relationships, 197 challenges, 338
Output, 194 characteristics, 330
Publisher-Subscriber model, 185 Class Diagram, 331
Solution Explorer View, 190 concept, 329
UI-based example, 188 definition, 329
Directed Graph Document, 332
exception, 337
P, Q, R Factory Method and Abstract Factory
Prototype pattern patterns, 436–437
BasicCar object, 18 implementation, 333–336
Class Diagram, 18–19 ISimpleFactory, 338
computer world example, 17 Output, 336
concept, 17 Solution Explorer View, 332–333
demonstration code, 27, 28 static class, 339
Directed Graph Document, 20 Wikipedia, 329
GoF definition, 17 Singleton pattern
implementation, 22–24 challenges, 10–11
Output, 24, 29 characteristics, 6
real-life example, 17 Class Diagram, 6
Solution Explorer View, 20–21 computer world example, 5
Proxy pattern concept, 5
and adapters, 435 vs. Factory Method pattern, 437
Class Diagram, 72 GoF definition, 5
computer world example, 71 implementation, 8–9
concept, 71 Output, 9–10
and decorators, 436 real-life example, 5
Directed Graph Document, 73 Solution Explorer View, 7
GoF definition, 71 static initialization, 7
implementation, 74–76 State pattern
modified implementation, 79–81 characteristics, 282

454
Index

Class Diagram, 271 challenges, 222


concept, 269 Class Diagram, 213
connection issues, 280 concept, 211
contexts, method parameters, 282 GoF definition, 211
Directed Graph Document, 272 implementation, 214, 216
GoF definition, 269 Modified Output, 221
implementation, 274–278 Modified Program, 218–220
job-processing system, 270 Output, 217
Output, 279 Solution Explorer View, 214
pros and cons, 282
real-world scenario, 279
Solution Explorer View, 272–273 V
Strategy pattern Visitor pattern
abstract class, 210 Class Diagram, 169
advantages, 210 Composite pattern
challenges, 210 implementation, 177–183
Class Diagram, 200 Output, 183
concept, 199 Solution Explorer View, 176
default behavior, 208, 210 tree structure, 173–176
Directed Graph Document, 201 concept, 167
GoF definition, 199 drawbacks, 184
implementation, 203–205 encapsulation, 184
inheritance mechanism, 206 GoF definition, 167
Output, 205 implementation, 170, 172
Solution Explorer View, 202 Output, 172
Static initialization, 7 public APIs, 168
Solution Explorer View, 170

T, U
Template Method pattern W, X, Y, Z
advantages, 222 Windows Presentation Foundation
BasicEngineering class, 217–218 (WPF), 224

455

You might also like