Singleton

Factory
Method

Builder
Abstract
Factory

Adapter
Composite
Bridge

Proxy
Command
Observer

Template
Method
Strategy

Design Patterns (GoF) in .NET

Aniruddha Chakrabarti
Senior Architect
Design Patterns (GoF)

Agenda
What is Design Pattern
History of Design Pattern
Background

Principles of OOP and OOAD

What is Good Design
Other Design Patterns and Principles (SOLID, GRASP)
Anti Patterns

Classification of different types of design patterns

Creational Design Patterns
Structural Design Patterns
Behavioral Design Patterns
Architecture Patterns (Brief)
Takeaway

Design Patterns (GoF)

OO Basic Tenants

Abstraction
Encapsulation
Polymorphism
Inheritance
Loose/Low Coupling
low dependency between classes;
low impact in a class of changes in other classes
high reuse potential

High Cohesion
measure of how strongly-related or focused the responsibilities of a
single module are
If methods of a class tend to be similar in many aspects, then the class
have high cohesion
In highly-cohesive system, code readability and the likelihood of reuse is
increased, while complexity is kept manageable
Design Patterns (GoF)

OO Principles
Encapsulate what varies
Favor Composition over Inheritance
(Dependencies injected with setters or constructor parameters)
Program to interface not implementation
Strive for loosely coupled design between objects that interact

Design Patterns (GoF)

Interface
Like an abstract base class: any non-abstract type inheriting
the interface must implement all its members.
Can not be instantiated directly.
Can contain events, indexers, methods and properties.
Contain no implementation of methods.
Classes and structs can inherit from more than one interface.
An interface can itself inherit from multiple interfaces.

Design Patterns (GoF)

Difference between Interface and abstract base class

Abstract class can have non abstract methods, methods of an interface are
effectively abstract since they contain only the signature
A class can implement any no of interfaces, but can subclass at most one
abstract class.
An abstract class can declare and use variables, an interface can not.
An abstract class can have methods whose access is public, internal,
protected, protected internal and private. Interface members implicitly
have public access.
An abstract class can declare constructor, an interface can not.
An abstract class can have delegate, an interface can not.

Design Patterns (GoF)

Interface Example Implicit Implementation

Does compile and work, but should be avoided

Object of type Interface should be used

Design Patterns (GoF)

Interface Example Explicit Implementation

Since the Interface is implemented explicitly,

it does NOT even compile

Object of type Interface should be used comp

and works perfectly.

Design Patterns (GoF)

Interface Example Business Logic Layer

Design Patterns (GoF)

Generic Interface Example

Design Patterns (GoF)

10

Generic Interface Example making it perfect

Design Patterns (GoF)

11

Class Relationship

Dependency
Association
Aggregation
Composition
Generalization / Inheritance

Design Patterns (GoF)

12

Dependency

Dependency - Weaker form of relationship which indicates that one class depends on
another because it uses it at some point of time.
Dependency exists if a class is a parameter variable or local variable of a method of
another class.

Design Patterns (GoF)

13

Association, Aggregation and Composition

Association Loose form of relationship
(Student can enroll in multiple Course, and
A Course can have multiple Student)

Aggregation - Whole part relationship.

Part can exist without Whole.
(Engine can exist even if Car is destroyed,
the same Engine could be used in a
different Car)

Composition Stronger form of whole

part relationship. Part can not exist without
Whole.
(OrderDetail can not exist if Order is
deleted. If Order is deleted, OrderDetail
also gets deleted)
Design Patterns (GoF)

14

Generalization / Inheritance

Design Patterns (GoF)

15

Design Principles (SOLID)

SOLID Principles are principles of class design.
SRP: Single Responsibility Principle
An object should have only a single responsibility & all the responsibility should be entirely
encapsulated by the class.
There should never be more than one reason for a class to change

OCP: Open/Closed Principle

Software entities should be open for extension, but closed for modification

LSP: Liskov Substituion Principle

Objects in a program should be replaceable with instances of their subtypes without
altering the correctness of that program

ISP: Interface Segregation Principle

many client specific interfaces are better than one general purpose interface
once an interface has gotten too 'fat' split it into smaller and more specific interfaces so
that any clients of the interface will only know about the methods that pertain to them. No
client should be forced to depend on methods it does not use

DIP: Dependency Inversion Principle

Depend upon Abstractions. Do not depend upon concretions.
Dependency Injection (DI) is one method of following this principle.

Design Patterns (GoF)

16

GRASP Pattern
Acronym for General Responsibility Assignment Software
Patterns.
Assigning responsibilities to classes is a critical aspect of
object-oriented design.
Appropriate assignment of responsibilities to classes is the key
to successful design.
There are fundamental principles in assigning responsibilities
that experienced designers apply.
These principles are summarized in the GRASP patterns.
Has nine core principles that object-oriented designers apply
when assigning responsibilities to classes and designing
message interactions.

Design Patterns (GoF)

17

GRASP Patterns (Contd)

Expert.
Creator.
Controller.
Low Coupling.
High Cohesion.
Polymorphism.
Pure Fabrication.
Indirection.
Dont Talk to Strangers.

Design Patterns (GoF)

18

Smell of good code

What is good code?
What is good design?

Maintainable/Readable/Easily understandable
Reusable
Easier to change if requirement chages
Performs better
Modular/Componentized
Takes care of all ility concerns

Design Patterns (GoF)

19

Smells within Class

Comments
Should only be used to clarify "why" not "what". Can quickly become verbose and reduce code
clarity.
Long Method
The longer the method the harder it is to see what its doing.
Long Parameter List
Don't pass everything the method needs. Pass enough so that the method gets everything it needs.
Duplicated Code
Large Class
A class that is trying to do too much can usually be identified by looking at how many instance
variables it has. When a class has too many instance variables, duplicated code cannot be far
behind.
Type Embedded in Name
Avoid redundancy in naming. Prefer Schedule.Add(course) to Schedule.AddCourse(course)
Uncommunicative Name
Choose names that communicate intent (pick the best name for the time, change it later if
necessary).
Inconsistent Names
Use names consistently.
Dead Code
A variable, parameter, method, code fragment, class is not used anywhere (perhaps other than in
tests).
Speculative Generality
Don't over-generalize your code in an attempt to predict future needs.

Design Patterns (GoF)

20

Smell Between Classes

Primitive Obsession

Data Class

Occurs when one class is commonly changed in different ways for different reasons. Any change to handle a
variation should change a single class.

Shotgun Surgery

When a class is delegating almost everything to another class, it may be time to refactor out the middle man.

Divergent Change

This is the case in which a client has to use one object to get another, and then use that one to get to another, etc.
Any change to the intermediate relationships causes the client to have to change.

Middle Man

Often a method that seems more interested in a class other than the one it's actually in. In general, try to put a
method in the class that contains most of the data the method needs.

Message Chains

Classes that aren't doing enough should be refactored away.

Feature Envy

Two classes are overly enter twined.

Lazy Class

Subclasses don't want or need everything they inherit. Liskov Substitution Principle (LSP) says that you should be
able to treat any subclass of a class as an example of that class.

Inappropriate Intimacy

Clumps of data items that are always found together.

Refused Bequest

Classes with fields and getters and setters and nothing else (aka, Data Transfer Objects - DTO)

Data Clumps

Use small objects to represent data such as money (which combines quantity and currency) or a date range object

The opposite of Divergent Change. A change results in the need to make a lot of little changes in several classes.

Parallel Inheritance Hierarchies

Special case of Shotgun Surgery. Every time you make a subclass of a class, you also have to make a subclass of
another.

Design Patterns (GoF)

21

What is Design Pattern

A pattern is a recurring solution to a standard problem, in
a context.
General reusable solution to a commonly occurring problem in
software design.
Extension of OOP and OOAD.
Description or template for how to solve a problem that can be
used in many different situations.
Mostly documented with the following sections

Intent
Motivation (Forces)
Structure
Participants
Implementation
Known Uses
Related Patterns

Design Patterns (GoF)

22

History of Design Patterns

Patterns originated as an architectural concept by Christopher Alexander 1977
Kent Beck and Ward Cunningham applied patterns to programming and
presented their results at OOPSLA conference - 1987
Gained popularity after the book Design Patterns: Elements of Reusable
Object-Oriented Software was published by "Gang of Four" (Erich Gamma,
Richard Helm, Ralph Johnson & John Vlissides) 1994
First Pattern Languages of Programming Conference was held 1994
Following year, the Portland Pattern Repository was set up for
documentation of design patterns.

Design Patterns (GoF)

23

List of Design Patterns - 23

Creational Patterns (ABFPS)

Singleton
Abstract Factory
Builder
Factory Method
Prototype

Structural Patterns
(ABCDFFP)

Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy

Design Patterns (GoF)

Behavioral Patterns
(2MICS On TV)

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

24

Singleton
Factory
Method

Builder
Abstract
Factory

Adapter
Composite
Bridge

Proxy
Command
Observer

Template
Method
Strategy

Creational Design Patterns

Design Patterns (GoF)

25

Singleton Pattern
Used to implement the mathematical concept of a singleton, by restricting
the instantiation of a class to one object.
Useful when exactly one object is needed to coordinate actions across the
system.
The concept is sometimes generalized to systems that operate more
efficiently when only one object exists, or that restrict the instantiation to a
certain number of objects (say, five).
Common Uses:
Abstract Factory, Builder and Prototype patterns can use Singletons in their
implementation.
Facade objects are often Singletons because only one Facade object is required.
Singletons are often preferred to global variables because:
They don't pollute the global name space (or, in languages with namespaces, their
containing namespace) with unnecessary variables.
They permit lazy allocation and initialization, whereas global variables in many
languages will always consume resources.

Design Patterns (GoF)

26

Singleton Class Diagram

Design Patterns (GoF)

27

Singleton in .NET BCL

HttpContext class in ASP.NET implements Singleton
The class can not be instantiated using new. The current instance of HttpContext
could be retrieved using HttpContext.Current property.
HttpContext.Current represents current ASP.NET Request context and this
context is available throughout the course of an ASP.NET request starting with
the HttpApplication.BeginRequest pipeline event all the way through
HttpApplication.EndRequest

OperationContext class in WCF (System.ServiceModel)

Provides access the current operation execution environment.
Used to access callback channels in duplex services, to store extra state data
across portions of the operations, and to access incoming message headers and
properties as well as add outgoing message headers and properties.

Design Patterns (GoF)

28

Implement Singleton in .NET (GoF way)

Advantages:
Because the instance is created inside the Instance property method, the class can
exercise additional functionality.
The instantiation is not performed until an object asks for an instance; this
approach is referred to as lazy instantiation. Lazy instantiation avoids instantiating
unnecessary singletons when the application starts.

Disadvantages:
Not safe for multithreaded environments. If separate threads of execution enter
the Instance property method at the same time, more that one instance of the
Singleton object may be created.
Design Patterns (GoF)

29

Thread Safe Singleton in .NET (using Static)

In this strategy, the instance is created the first time any member of the
class is referenced. CLR takes care of the variable initialization. The class
is marked sealed to prevent derivation, which could add instances.
In addition, the variable is marked readonly, which means that it can be
assigned only during static initialization (which is shown here) or in a
class constructor.
Design Patterns (GoF)

30

Multithreaded Singleton in .NET

In some cases we cannot rely on the CLR to

ensure thread safety, as in the Static
Initialization example should use specific
language capabilities to ensure that only one
instance of the object is created in the presence
of multiple threads.
One of the more common solutions is to use the
Double-Check Locking idiom to keep separate
threads from creating new instances of the
singleton at the same time.
Ensures only one instance is created and only
when the instance is needed. Variable is declared
volatile to ensure that assignment to instance
variable completes before instance variable can
be accessed.
Lastly, it uses a syncRoot instance to lock on,
rather than locking on the type itself, to avoid
deadlocks.

Double-check locking approach solves thread concurrency problems while avoiding an exclusive lock in every
call to the Instance property method. Also allows you to delay instantiation until the object is first accessed.
In practice, an application rarely requires this type of implementation. In most cases, the static initialization
approach is sufficient.

Design Patterns (GoF)

31

Factory Method
Define an interface for creating an object, but let subclasses decide which
class to instantiate.
Factory Method lets a class defer instantiation tosubclasses.

Design Patterns (GoF)

32

Factory Method in .NET BCL Collection

GetEnumerator() returns
an specific enumerator
type based on the collection
class

Design Patterns (GoF)

33

Factory Method in .NET BCL Collection

Design Patterns (GoF)

34

How to implement Factory Method in .NET

Design Patterns (GoF)

35

Abstract Factory Pattern

Provides a way to encapsulate a group of individual factories that have a
common theme.
In normal usage, the client software creates a concrete implementation of
the abstract factory and then uses the generic interfaces to create the
concrete objects that are part of the theme.
Client does not know (or care) which concrete objects it gets from each of
these internal factories since it uses only the generic interfaces of their
products. It separates details of implementation of a set of objects from
their general usage.

Design Patterns (GoF)

36

Factory in .NET: DbProviderFactory

Design Patterns (GoF)

37

Factory in .NET: DbProviderFactory

Design Patterns (GoF)

38

Factory in .NET: DbProviderFactory

Design Patterns (GoF)

39

Implement Factory in .NET

//The context passed determines
return type

Design Patterns (GoF)

40

Configuration based Abstract Factory

Design Patterns (GoF)

41

Builder Pattern
Separate construction of a complex object from its representation so that
the same construction process can create differentrepresentations.
Parse a complex representation, create one of severaltargets.
Difference Between Builder and Factory
Builder focuses on constructing a complex object step by step. Abstract Factory
emphasizes a family of product objects - simple or complex.
Builder returns the product as a final step, but as far as the Abstract Factory is
concerned, the product gets returned immediately.

Builder often builds a Composite.

Design Patterns (GoF)

42

Builder Design Pattern

Builder focuses on constructing a complex object step by step. Abstract
Factory emphasizes a family of product objects (either simple or complex).
Builder returns the product as a final step, but as far as the Abstract
Factory is concerned, the product gets returned immediately.
Builder often builds a Composite.
Often, designs start out using Factory Method (less complicated, more
customizable, subclasses proliferate) and evolve toward Abstract Factory,
Prototype, or Builder (more flexible, more complex).
Sometimes creational patterns are complementary: Builder can use one of
the other patterns to implement which components are built. Abstract
Factory, Builder, and Prototype can use Singleton in their implementations.

Design Patterns (GoF)

43

Builder Pattern in .NET BCL

Design Patterns (GoF)

44

Builder: SqlConnectionStringBuilder in .NET

Design Patterns (GoF)

45

Builder: StringBuilder & UriBuilder in .NET

Design Patterns (GoF)

46

Implement Builder Pattern in .NET (non Generic)

Design Patterns (GoF)

47

Implement Builder Pattern in .NET (Generic)

Design Patterns (GoF)

48

Implement Builder Pattern in .NET

Design Patterns (GoF)

49

Builder Pattern in .NET

Design Patterns (GoF)

50

Prototype Design Pattern

Specify the kinds of objects to create using a prototypical instance, and
create new objects by copying thisprototype.
Co-opt one instance of a class for use as a breeder of all futureinstances.

Design Patterns (GoF)

51

Prototype in .NET BCL

Prototype is achieved in .NET BCL in two ways
Using Object.MemberwiseClone protected method
Performs Shallow Copy of members
Shallow Copy is provided out-of the box by .NET BCL

Using ICloneable BCL interface

Need to be implemented by classes implementing ICloneable
Provides a method called Clone
Should provide Deep Copy of members

Design Patterns (GoF)

52

Deep Copy vs. Shallow Copy

Before

originalEmployee
:Employee

originalAddress
:Address

originalEmployee
:Employee

originalAddress
:Address

originalEmployee
:Employee

originalAddress
:Address

originalEmployee
:Employee

originalAddress
:Address

newEmployee
:Employee

newAddress
:Address

After
newEmployee
:Employee

Shallow Copy

Design Patterns (GoF)

Deep Copy

53

Implement Prototype in .NET

Non Generic version

Design Patterns (GoF)

Better Generic version

54

Prototype (Shallow Copy)

Design Patterns (GoF)

55

Prototype (Deep Copy)?

Design Patterns (GoF)

56

Dependency Injection (DI)

Design Patterns (GoF)

57

DI Example - Unity
Lightweight, extensible dependency injection container
Supports interception, constructor injection, property injection, and method
call injection
Part of MS Enterprise Library Application Block

Design Patterns (GoF)

58

Unity Example

Design Patterns (GoF)

59

Unity Example

Design Patterns (GoF)

60

Singleton
Factory
Method

Builder
Abstract
Factory

Adapter
Composite
Bridge

Proxy
Command
Observer

Template
Method
Strategy

Structural Design Patterns

Design Patterns (GoF)

61

Adapter Design Pattern

Adapter pattern (also called wrapper pattern or wrapper) translates one
interface for a class into a compatible interface.
Allows classes to work together that normally could not because of
incompatible interfaces, by providing its interface to clients while using the
original interface.
The adapter translates calls to its interface into calls to original interface.
Amount of code necessary to do this is typically small.
The adapter is also responsible for transforming data into appropriate
forms.
Often used while working with existing API/code base and while adapting
code for which no source is not available.
Could be of two types
Object Adapter
Class Adapter

Design Patterns (GoF)

62

Adapter Class Diagram

Design Patterns (GoF)

63

Adapter Pattern in ADO.NET

Data Adapters adapts data from different source (SQL Server, Oracle,
ODBC, OLE DB) to dataset which is data-source unaware
Different Data Adapter classes are used
SqlDataAdapter
OdbcDataAdapter
OleDbDataAdapter

Design Patterns (GoF)

64

Adapter Pattern in ADO.NET Contd

Design Patterns (GoF)

65

Implement Adapter Pattern in .NET

Object Adapter

Design Patterns (GoF)

66

Implement Adapter Pattern in .NET

Class Adapter

Design Patterns (GoF)

67

Adapter for extracting data

Design Patterns (GoF)

68

Composite Design Pattern

Describes that a group of objects are to be treated in the same
way as a single instance of an object. Intent is to "compose"
objects into tree structures to represent part-whole hierarchies.
Implementing the composite pattern lets clients treat
individual objects and compositions uniformly
Compose objects into tree structures to represent whole-part
hierarchies. Composite lets clients treat individual objects and
compositions of objectsuniformly.
Recursive Composition
Directories contain entries, each of which could be
adirectory.
1-to-many has a up the is ahierarchy

Design Patterns (GoF)

69

Composite Pattern Class Diagram

Design Patterns (GoF)

70

Implement Composite in .NET

Design Patterns (GoF)

71

Implement Composite in .NET (Contd)

Design Patterns (GoF)

72

Composite Pattern in .NET Org Tree

Design Patterns (GoF)

73

Composite Pattern in .NET Org Tree

Design Patterns (GoF)

74

Decorator Pattern
Attach additional responsibilities to an object dynamically. Decorators
provide a flexible alternative to subclassing for extendingfunctionality.
Client-specified embellishment of a core object by recursively wrappingit.
Wrapping a gift, putting it in a box, and wrapping the box
You want to add behavior or state to individual objects at runtime. Inheritance is not feasible because it is static and applies to
an entireclass.

Design Patterns (GoF)

75

Decorator in .NET BCL - System.IO

Design Patterns (GoF)

76

Decorator in WPF

Design Patterns (GoF)

77

Implementing Decorator in .NET

Base.Display() + added behaviour

(decoration)
Design Patterns (GoF)

78

Implementing Decorator in .NET (Contd)

Design Patterns (GoF)

79

Implementing Decorator in .NET (Contd)

Design Patterns (GoF)

80

Bridge

Decouple an abstraction from its implementation so that the two can vary independently.
The Bridge pattern is useful when there is a hierarchy of abstractions and a corresponding hierarchy of
implementations. Rather than combining the abstractions and implementations into many distinct
classes, the Bridge pattern implements the abstractions and implementations as independent classes
that can be combined dynamically.
Bridge pattern has nearly the same structure as the Adapter Pattern. But it is used when designing
new systems instead of the Adapter pattern which is used with already existing systems.
Based on the principle Prefer Composition (and Association, Aggregation) over Inheritance
Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy
Beyond encapsulation, to insulation

Design Patterns (GoF)

81

Bridge Pattern Thread Scheduler

Design Patterns (GoF)

82

Bridge Pattern Thread Scheduler (Contd)

A new type of Platform (JVM) is added.

What happens if another type of scheduler is added and No of Platforms increase to
four from three
No of classes increases exponentially - Inheritance Hierarchy become complex,
bloated and difficult to maintain.
Design Patterns (GoF)

83

Bridge Example

Decompose the component's interface and implementation into orthogonal class hierarchies.
Abstract/Interface class contains a pointer to abstract implementation class. This pointer is
initialized with an instance of a concrete implementation class, but all subsequent interaction
from the interface class to the implementation class is limited to the abstraction maintained in
the implementation base class.
Client interacts with interface class - "delegates" all requests to implementation class.

Design Patterns (GoF)

84

Bridge

Design Patterns (GoF)

85

Proxy Design Pattern

Provide a surrogate or placeholder for another object to control access toit.
Use an extra level of indirection to support distributed, controlled, or
intelligentaccess.
Add a wrapper and delegation to protect the real component from
unduecomplexity.

Design Patterns (GoF)

86

Proxy in .NET (WCF)

Contract

Contract Implementation

Host
Design Patterns (GoF)

87

Proxy in .NET (WCF) Contd

Proxy

Client

Cannot have two operations in the same contract with the same name, methods Add and Add in
type ConsoleApplication1.ICalculatorService violate this rule. You can change the name of one of
the operations by changing the method name or by using the Name property of
OperationContractAttribute.
Design Patterns (GoF)

88

Solution

Design Patterns (GoF)

89

How to implement Proxy in .NET

Client

Online

Offline

Not Public (Protected/Private)

Design Patterns (GoF)

90

Singleton
Factory
Method

Builder
Abstract
Factory

Adapter
Composite
Bridge

Proxy
Command
Observer

Template
Method
Strategy

Behavioral Design Patterns

Design Patterns (GoF)

91

Command Design Pattern

Encapsulate a request as an object, thereby letting you parameterize
clients with different requests, queue or log requests, and support
undoableoperations.
Design Pattern in which an object is used to represent and encapsulate all
infos needed to call a method later - info include method name, object that
owns the method and values of method parameters.
Promote invocation of a method on an object to full objectstatus
An object-orientedcallback

Design Patterns (GoF)

92

Observer Design Pattern

Define a one-to-many dependency between objects so that when one
object changes state, all its dependents are notified and
updatedautomatically.
Encapsulate the core (or common or engine) components in a Subject
abstraction, and the variable (or optional or user interface) components in
an Observerhierarchy.
The View part ofModel-View-Controller.

View

Design Patterns (GoF)

Model

93

Observer design pattern in .NET

delegates and events provides a powerful means of
implementing the Observer pattern.
As delegates and events are first class members of CLR, the
foundation of this pattern is incorporated into core of .NET
Framework.
FCL makes extensive use of Observer pattern throughout its
structure.

Design Patterns (GoF)

94

Implement an Event

3. Determine when to raise the event in the class. Call

OnEventName to raise the event.
1. Define a public event member in class. Set the type
of event member to System.EventHandler delegate.
2. Provide a protected method in the class that raises
the event. Name the method OnEventName. Raise the
event within the method

Client can register for the events they

are interested.
Client can un-register for the events
they have already registered.

Design Patterns (GoF)

95

Implement an Event with Event specific data

Design Patterns (GoF)

96

IObserver<T> and IObservable<T> in .NET 4

.NET 4.0 introduces two new interfaces in BCL that implements Observer
pattern - are part of larger Reactive/Rx framework
The IObserver<T> and IObservable<T> interfaces provide a generalized
mechanism for push-based notification
IObservable<T> interface represents the class that sends notifications (the
provider)
IObserver<T> interface represents the class that receives them (the observer)

IObserver

View

Design Patterns (GoF)

Push

IObservable

Model

97

IObserver<T> and IObservable<T>

Design Patterns (GoF)

98

Template Method Pattern

Define the skeleton of an algorithm in an operation, deferring some steps
to client subclasses. Template Method lets subclasses redefine certain steps
of an algorithm without changing algorithmsstructure.
Base class declares algorithm placeholders, and derived classes
implement theplaceholders.
Has similarity with Strategy pattern.

Design Patterns (GoF)

99

Template Method Pattern in .NET BCL (Sorting)

Since String class implements IComparable Array.Sort (and Sort method of all collection classes
including Generic and non-Generic collection classes) uses string's IComparable implementation
to sort the array (String.CompareTo is used).

Design Patterns (GoF)

100

Template Method Pattern in .NET BCL (Contd)

Design Patterns (GoF)

101

Template Method in .NET BCL IComparable

Employee class now implements IComparable
interface which has a single method int
CompareTo(object)

Design Patterns (GoF)

102

Template Method in .NET BCL IComparable<T>

Employee class implements two interface
IComparable (non Generic) which has a single
method int CompareTo(object)
IComparable<T> (Generic) which has another
overload of CompareTo int CompareTo(T)

Design Patterns (GoF)

Generic version of CompareTo is used by CLR if

both non
generic and generic versions are present.
Always prefer implementing IComparable<T> for
better
performance (no boxing, unboxing overhead) 103

Template Method in .NET BCL - IComparer

Design Patterns (GoF)

104

Template Method in .NET BCL - IComparer<T>

Generic version of IComparer

is used by CLR if both non
Generic and Generic version is
present.
Always prefer implementing
IComparer <T> for better
performance (no boxing,
unboxing overhead)

Design Patterns (GoF)

105

Implement Template Method Pattern in .NET

Design Patterns (GoF)

106

Implement Template Method Pattern in .NET (Contd)

Design Patterns (GoF)

107

Template Method Pattern Example 2

Design Patterns (GoF)

108

Template Method Pattern Example 2

Design Patterns (GoF)

109

Alternate Template Method Implementation (using Interface)

Design Patterns (GoF)

110

Strategy Design Pattern

Strategy pattern (also known as the policy pattern) is a design pattern,
whereby algorithms can be selected at runtime.
Intended to provide a means to define a family of algorithms, encapsulate
each one as an object, and make them interchangeable.
The strategy pattern lets the algorithms vary independently from clients
that use them.
For example, while sorting has many algorithm (like binary sort, quick sort),
the sorting algorithm is independent of how to objects/elements are
compared. So the sorting algorithm can vary/change independent of
compare algorithm.

Design Patterns (GoF)

111

Before using Strategy

Design Patterns (GoF)

112

After Refactoring with Strategy

Design Patterns (GoF)

113

After Refactoring with Strategy

Design Patterns (GoF)

114

After Refactoring with Strategy (Contd)

Design Patterns (GoF)

115

Template Method in ASP.NET Controls

Different options for custom controls
For simple controls used in single project, user control is best choice.
Control used in several Web applications or requires more functionality, a
custom server control may be a better fit. There are two general types:
Controls that combine the functionality of several existing controls (called composite
controls),
Controls with a unique visual representation.
Process for creating both of these types is very similar. For composite controls, create a
new class that inherits from control base classes (like Control or WebControl) and then
override the CreateChildControls method. In this method add controls whose
functionality you are combining to the collection of child controls, called Controls.
For other custom controls, you override Render instead and use the HtmlTextWriter
parameter to output the HTML for your control directly.
Regardless of which style of custom control you choose, you don't have to write any
code to handle the functionality that's common to all controls, like loading and saving
ViewState at the right time, allowing PostBack events to be handled, and making sure
the control lifecycle events are raised in the correct order. The main algorithm for how
a control should be loaded, rendered, and unloaded is contained in the control base
class.

Design Patterns (GoF)

116

Difference between Template and Strategy

Strategy is used to allow callers to vary an entire algorithm, like how to
compare two objects, while Template Method is used to vary steps in an
algorithm.
Because of this, Strategy is more coarsely grained.
There can be vast differences between different client implementations,
while with Template Method the algorithm remains fundamentally the
same.
Strategy uses delegation while Template Method uses inheritance. In the
sorting example of Strategy, the comparison algorithm is delegated to the
IComparer parameter, but with custom controls you subclass the base and
override methods to make changes. Both, however, let you easily alter
processes to fit your specific needs.

Design Patterns (GoF)

117

AntiPatterns
Pattern that may be commonly used but is ineffective and/or
counterproductive in practice.
The term was coined in 1995 by Andrew Koenig inspired by Gang of Four's
book Design Patterns,
The term was widely popularized three years later by the book AntiPatterns

Design Patterns (GoF)

118

Organizational AntiPatterns
Analysis paralysis: Devoting disproportionate effort to the analysis phase of a
project
Cash cow: A profitable legacy product that often leads to complacency about new
products
Design by committee: The result of having many contributors to a design, but no
unifying vision
Moral hazard: Insulating a decision-maker from the consequences of his or her
decision.
Stovepipe or Silos: A structure that supports mostly up-down flow of data but
inhibits cross organizational communication
Vendor lock-in: Making a system excessively dependent on an externally supplied
component

Design Patterns (GoF)

119

Software Design AntiPatterns

Abstraction inversion: Not exposing implemented functionality required by users, so
that they re-implement it using higher level functions
Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and
design (OOAD)) without specifying its viewpoint
Big ball of mud: A system with no recognizable structure
Database-as-IPC: Using database as message queue for interprocess
communication where a more lightweight mechanism would be suitable
Gold plating: Continuing to work on a task or project well past the point at which
extra effort is adding value
Inner-platform effect: A system so customizable as to become a poor replica of the
software development platform
Input kludge: Failing to specify and implement the handling of possibly invalid input
Interface bloat: Making an interface so powerful that it is extremely difficult to
implement
Magic pushbutton: Coding implementation logic directly within interface code,
without using abstraction.
Race hazard: Failing to see the consequence of different orders of events
Stovepipe system: A barely maintainable assemblage of ill-related components

Design Patterns (GoF)

120

Object Oriented Design AntiPattern

Anemic Domain Model: Use of domain model without business logic. The domain model's
objects cannot guarantee their correctness at any moment, because their validation
logic is placed somewhere outside (most likely in multiple places).
BaseBean: Inheriting functionality from a utility class rather than delegating to it
Call super: Requiring subclasses to call a superclass's overridden method
Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
Circular dependency: Introducing unnecessary direct or indirect mutual dependencies
between objects or software modules
Constant interface: Using interfaces to define constants
God object: Concentrating too many functions in a single part of design (class)
Object cesspool: Reusing objects whose state does not conform to the (possibly implicit)
contract for re-use
Object orgy: Failing to properly encapsulate objects permitting unrestricted access to
their internals
Poltergeists: Objects whose sole purpose is to pass information to another object
Sequential coupling: A class that requires its methods to be called in a particular order
Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to
excessive fragmentation

Dependency hell: Problems with versions of required products

DLL hell: Inadequate management of dynamic-link libraries (DLLs), specifically on Microsoft
Windows

Design Patterns (GoF)

121

Programming AntiPattern

Accidental complexity: Introducing unnecessary complexity into a solution

Action at distance: Unexpected interaction between widely separated parts of system
Blind faith: Lack of checking of correctness of a bug fix or result of a subroutine
Boat anchor: Retaining a part of a system that no longer has any use
Busy spin: Consuming CPU while waiting for something to happen, usually by repeated
checking instead of messaging
Caching failure: Forgetting to reset an error flag when an error has been corrected
Cargo cult programming: Using patterns and methods without understanding why
Coding by exception: Adding new code to handle each special case as it is recognized
Error hiding: Catching an error message before it can be shown to the user and either showing
nothing or showing a meaningless message
Hard code: Embedding assumptions about environment of a system in its implementation
Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too
expensive or has unpredictable consequences
Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop
statement
Magic numbers: Including unexplained numbers in algorithms
Magic strings: Including literal strings in code, for comparisons, as event types etc.
Soft code: Storing business logic in configuration files rather than source code[7]
Spaghetti code: Programs whose structure is barely comprehensible, especially because of
misuse of code structures

Design Patterns (GoF)

122

Methodological AntiPatterns
Copy and paste programming: Copying (and modifying) existing code rather than
creating generic solutions
Golden hammer: Assuming that a favorite solution is universally applicable
Improbability factor: Assuming that it is improbable that a known error will occur
Not Invented Here (NIH) syndrome: The tendency towards reinventing the wheel
(Failing to adopt an existing, adequate solution)
Premature optimization: Coding early-on for perceived efficiency, sacrificing good
design, maintainability, and sometimes even real-world efficiency
Programming by permutation (or "programming by accident"): Trying to approach a
solution by successively modifying the code to see if it works
Reinventing the wheel: Failing to adopt an existing, adequate solution
Reinventing the square wheel: Failing to adopt an existing solution and instead
adopting a custom solution which performs much worse than the existing one.
Silver bullet: Assuming that a favorite technical solution can solve a larger process
or problem
Tester Driven Development: Software projects in which new requirements are
specified in bug reports

Design Patterns (GoF)

123

Resources

Discover the Design Patterns You're Already Using in the .NET Framework
Exploring the Observer Design Pattern
Observer Design Pattern in .NET 4
AntiPattern
AntiPattern: Wikipedia

Design Patterns (GoF)

124

Facade
Facade or Faade is generally one side of the exterior of a building,
especially the front, but also sometimes the sides and rear.
The word comes from the French language, literally meaning "frontage" or
"face".

Carlo Maderno's monumental faade of Saint Peter's basilica in Vatican City

Design Patterns (GoF)

125

Faade Pattern
A facade is an object that provides a simplified interface to a larger body of
code, such as a class library. A facade can:
Make a software library easier to use, understand and test, since the facade has
convenient methods for common tasks
Make code that uses the library more readable, for the same reason
Reduce dependencies of outside code on the inner workings of a library, since
most code uses the facade, thus allowing more flexibility in developing the
system
Wrap a poorly-designed collection of APIs with a single well-designed API

Design Patterns (GoF)

126

Faade in .NET Visual Basic - My namespace

My namespace
Application: Gets access to Application object
Computer: Contains info about computer like Audio, Clock Clipboard,
File System, Registry, Keyboard, Mouse, Screen, Network, Ports etc
Forms: Provides access to all Forms in a Win Forms App
Settings: Provides access to Settings collection
User: Points to the current logged in user (Principal, Role)
WebService: Provides access to all Web Services referenced

Design Patterns (GoF)

127

Implementing Faade in .NET

Sub System A

Sub System B

Sub System C

Design Patterns (GoF)

128

Implementing Faade in .NET (Contd)

Design Patterns (GoF)

129

Iterator in .NET: Enumerator

Design Patterns (GoF)

130

Mediator class diagram

Design Patterns (GoF)

131

Mediator

Design Patterns (GoF)

132

Mediator

Design Patterns (GoF)

133

Mediator

Design Patterns (GoF)

134

Flyweight in .NET BCL

String Interning in .NET (Java also does the same)

Design Patterns (GoF)

135

Flyweight in .NET BCL (Contd)

Design Patterns (GoF)

136

State Design Pattern

Supports an object that has several states
The state an object determines the behavior of several methods. Without State
pattern could be implemeted with if else / swicth case statements in each
method
Better solution: state pattern
Have a reference to a state object
Normally, state object doesnt contain any fields
Change state: change state object
Methods delegate to state object

Design Patterns (GoF)

137

Without State Pattern

Design Patterns (GoF)

138

Implementing State Pattern in .NET

Different classes representing different states of the object (CD Player)

Each State specific class implements an interface (ICDPlayerStateChange)
Each State specific class contains the code for the state change. The object (CDPlayer) simply
delegates the call to these state specific classes.
State of the object (CD Player) is managed by new State specific classes.

Design Patterns (GoF)

139

Implementing State Pattern in .NET (Contd)

Design Patterns (GoF)

140

Implementing State Pattern in .NET (Contd)

Design Patterns (GoF)

141

Chain of Responsibility
Decouples the sender of the request to the receiver. The only link between
sender and the receiver is the request which is sent. Based on the request
data sent, the receiver is picked. This is called data-driven.
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 handlesit.
Launch-and-leave requests with a single processing pipeline that contains
many possiblehandlers.
Promotes the idea of loose coupling.

Design Patterns (GoF)

142

Implementing Chain of Resp. in .NET

Handler abstract base class

Concrete Handler classes

Design Patterns (GoF)

143

Implementing Chain of Resp. in .NET

Design Patterns (GoF)

144

Implementing Chain of Resp. in .NET

Design Patterns (GoF)

145

Implementing Chain of Resp. in .NET

Design Patterns (GoF)

146

Implementing Chain of Resp. in .NET

ApprovalManager class acts like a Faade.
You may not use this class - you can directly
instantiate SeniorManager class from client.
The advantage of using a Faade is any
change in hierarchy would be encapsulated
from the client, as it would be handled in
ApprovalManager class.

Design Patterns (GoF)

147