The first session on design patterns that makes the audience aware of the patterns. P.S. The implementation are more from explanation perse rather than focusing on being 100% correct. The idea is to make the audience understand patterns rather than putting 100% correct code for the pattern.

1. Segue to Design Patterns
Being aware of Design Patterns is the beginning of creating better design
Rahul Rajat Singh

2. Agenda
• OO Principles
• Design Principles (SOLID)
• Looking a big ball of Mud
• What are Design Patterns
• Types and List of Design Patterns
• Singleton Pattern
• Factory Method
• Adapter Design Pattern
• Strategy Design Pattern
• Revisiting the big ball of mud and refactor

3. OO Principles
• Encapsulate what varies
• Favour Composition over Inheritance
• Program to interface not implementation
• Strive for loosely coupled design between objects that interact

4. Design Principles (SOLID)
• 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

5. Looking a big ball of Mud
Problems
• SRP
• OCP
• DIP

6. What are Design Patterns
• 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.

7. Types and List of Design Patterns
• Creational Patterns
Deals with controlled object creation
• Singleton
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Structural Patterns
Deals with composition of classes or
objects
• Adapter
• Bridge
• Composite
• Decorator
• Façade
• Flyweight
• Proxy
• Behavioural Patterns
Deals with interaction between objects
• Chain of
Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

8. 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.

9. Implement Singleton in .NET
• Advantages:
• Because the instance is created inside the Instance property method, the class can exercise
additional functionality.
• Lazy instantiation avoids instantiating unnecessary singletons when the application starts.
• Disadvantages:
• Not safe for multithreaded environments (Highly advisable to check the thread safe implantation
too)

10. 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.

11. Implement Factory Method in .NET

12. Adapter Design Pattern
• Adapter pattern 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.

13. Implementing Adaptor

14. 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.

15. Implement Strategy pattern

16. Revisiting the big ball of mud and refactor
Let’s Fix issues
• SRP – Having separate classes
responsible for each payment
gateway. The classes will be the
Adaptors for each payment
gateway.
• DIP – The Adaptors will implement
a common interface and this class
will depend on interface. So our
payment classes will also be
concrete strategies.
• OCP – Let’s inject these concrete
strategies using a factory class.

17. SRP – Separate Adaptors classes for each payment gateway
SBIPaymentGateway
bool InitiatePayment()
PayPalPaymentGateway
bool InitiatePayment()
BillDeskPaymentGateway
bool InitiatePayment()
HDFCPaymentGateway
bool InitiatePayment()

18. Getting DIP ready by making converting our adaptors to concrete strategy
SBIPaymentGateway
bool InitiatePayment()
PayPalPaymentGateway
bool InitiatePayment()
BillDeskPaymentGateway
bool InitiatePayment()
HDFCPaymentGateway
bool InitiatePayment()
<<Interface>>
IPaymentGateway
bool InitiatePayment()

19. Inversion of control and OCP support by implementing Factory
Note: A ServiceLocator or IOC container can also be used instead of factory to achieve inversion of
control.

20. Making the Factory Singleton

21. How to Select a Design Pattern – Ask yourself
• What do they do?
• What do they decouple/couple?
• When should you use them?
• When should you not use them?
• What missing language feature would make them go away?
• What technical debt do you incur by using it?
• Is there a simpler way to get the job done?

22. References