Part 1 - Introduction

Design Patterns for .
NET
Part 1 - Introduction
The concept of a ‘Software Design Pattern’ was adopted from the idea of a building
design pattern in the field of building design and architecture. For more information, refer
to the book ‘The Timeless Way of Building by Christopher Alexander’. Within the
context of software engineering, a Design Pattern is the official term given to a design
concept that encompasses the idea of reuse and communication. Simply stated, Design
Patterns are tried and tested solutions to common and recurring challenges. At their core,
design patterns are the manifestation of good object-oriented design principles.
Design Patterns are important to understand for the following reasons:
• They give us reuse
• Once a design pattern has emerged to solve a particular problem, that design
pattern can be applied countless times on future tasks where a similar problem
may arise. It can also be used by countless others who may encounter similar
problems.
• The give us a common taxonomy allowing for better communication
• Design patterns allow one to refer to a design concept without explaining the full
detail of that concept. How often has one heard a conversation along the lines of
the following?
Developer A: “Remember that thingy we used last time to solve a problem similar to this
one.”
Team: “What thingy?”
Developer A: “That thingy where we allowed only a single instance of an object to exist
at any given time”
Team: “Heh!?”
Imagine the development team has reached a certain level of maturity in terms of design
thinking and design patterns. The conversation would instead sound something like this.
Developer A: “We should use a Singleton to solve this.”
Team: “A Singleton will work. And we could use a Façade for the Products sub-system.”
As one can see, a Design Pattern speaks a thousand words. It is also far more professional
and efficient to speak of well documented concepts than a ‘thingy’.
• They give us a higher level of abstraction in terms of analysis and design
This allows one to think of the larger design in terms of smaller component areas.
Therefore, when one looks at the bigger picture, one can visualize it in terms of its
constituent parts.
• Fosters design thinking
If one is to understand object-oriented design principles, it is beneficial to understand

design patterns. However, if one is to understand design patterns, one must understand
object-oriented design. The two concepts (OO Design and Design Patterns) compliment
each other. This will intern compliment ones development code.
Part 2 – GOF Design Patterns

The book that has profoundly influenced design pattern theory is Design Patterns:
Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and
Vlissides. The aforementioned four authors are commonly known as the Gang of Four
(GOF). Many, including myself have referred to this book as the Bible of software design
patterns. Although many have questioned the relevance of the design patterns catalogued
in this book. The fact remains that it helps provide a solid foundation from which to build
ones design pattern knowledge. This is where we shall start.
The GOF book catalogued 23 design patterns into 3 groups, namely Creational, Structural
and Behavioural. I have adopted the intent of the design patterns as per the GOF book.
Creational
Abstract Factory Provide an interface for creating families of related or
dependent objects without specifying their concrete
classes.
Builder Separate the construction of a complex object from its

representation so that the same construction process can
create different representations.
Factory Method Define an interface for creating an object, but let

subclasses decide which class to instantiate. Factory
Method lets a class defer instantiation to subclasses.
Prototype Specify the kinds of objects to create using a prototypical

instance, and create new objects by copying this
prototype.
Singleton Ensure a class only has one instance, and provide a global
point of access to it.
Structural
Adapter Convert the interface of a class into another interface
clients expect. Adapter lets classes work together that
couldn't otherwise because of incompatible interfaces.
Bridge Decouple an abstraction from its implementation so that

the two can vary independently.
Composite Compose objects into tree structures to represent part-

whole hierarchies. Composite lets clients treat individual
objects and compositions of objects uniformly.
Decorator Attach additional responsibilities to an object

dynamically. Decorators provide a flexible alternative to
subclassing for extending functionality.
Façade Provide a unified interface to a set of interfaces in a

subsystem. Facade defines a higher-level interface that
makes the subsystem easier to use.
Flyweight Use sharing to support large numbers of fine-grained

objects efficiently.
Proxy Provide a surrogate or placeholder for another object to

control access to it.
Behavioural
Chain Of Responsibility 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.
Command Encapsulate a request as an object, thereby letting you

parameterize clients with different requests, queue or log
requests, and support undoable operations.
Interpreter Given a language, define a representation for its grammar

along with an interpreter that uses the representation to
interpret sentences in the language.
Iterator Provide a way to access the elements of an aggregate

object sequentially without exposing its underlying
representation.
Mediator Define an object that encapsulates how a set of objects

interact. Mediator promotes loose coupling by keeping
objects from referring to each other explicitly, and it lets
you vary their interaction independently.
Memento Without violating encapsulation, capture and externalize

an object's internal state so that the object can be restored
to this state later.
Observer Define a one-to-many dependency between objects so

that when one object changes state, all its dependents are
notified and updated automatically.
State Allow an object to alter its behaviour when it’s internal

state changes. The object will appear to change its class.
Strategy Define a family of algorithms, encapsulate each one, and

make them interchangeable. Strategy lets the algorithm
vary independently from clients that use it.
Template Method Define the skeleton of an algorithm in an operation,

deferring some steps to subclasses. Template Method lets
subclasses redefine certain steps of an algorithm without
changing the algorithm's structure.
Visitor Represent an operation to be performed on the elements

of an object structure. Visitor lets you define a new
operation without changing the classes of the elements on
which it operates.

Part 1 - Introduction

Uploaded by

Copyright:

Available Formats

Part 1 - Introduction

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Part 1 - Introduction

Uploaded by

Copyright:

Available Formats

Design Patterns for .

Design Patterns are important to understand for the following reasons:

• They give us reuse

• The give us a common taxonomy allowing for better communication

Team: “What thingy?”

Developer A: “We should use a Singleton to solve this.”

• They give us a higher level of abstraction in terms of analysis and design

• Fosters design thinking

If one is to understand object-oriented design principles, it is beneficial to understand

Part 2 – GOF Design Patterns

Builder Separate the construction of a complex object from its

Factory Method Define an interface for creating an object, but let

Prototype Specify the kinds of objects to create using a prototypical

Bridge Decouple an abstraction from its implementation so that

Composite Compose objects into tree structures to represent part-

Decorator Attach additional responsibilities to an object

Façade Provide a unified interface to a set of interfaces in a

Flyweight Use sharing to support large numbers of fine-grained

Proxy Provide a surrogate or placeholder for another object to

Command Encapsulate a request as an object, thereby letting you

Interpreter Given a language, define a representation for its grammar

Iterator Provide a way to access the elements of an aggregate

Mediator Define an object that encapsulates how a set of objects

Memento Without violating encapsulation, capture and externalize

Observer Define a one-to-many dependency between objects so

State Allow an object to alter its behaviour when it’s internal

Strategy Define a family of algorithms, encapsulate each one, and

Template Method Define the skeleton of an algorithm in an operation,

Visitor Represent an operation to be performed on the elements

You might also like