1. Software Design Patterns
Gang of Four (GoF, made up of Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

2. What is Design Pattern?
Design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”
—GANG OF FOUR
Design patterns offer solutions to common application design problems.
In object-oriented programming, design patterns are normally targeted at solving the problems associated with object creation and interaction, rather than the large-scale problems faced by the overall software architecture.
They provide generalized solutions in the form of boilerplates that can be applied to real-life problems.

3. Design Patterns are visualized using a class diagram
They show the behaviors and relations between classes
Diagram shows the inheritance relationship between three classes.
The subclasses CheckingAccount and SavingsAccount inherit from their abstract parent class BankAccount.

4. public class SingleObject {
//create an object of SingleObject
private static SingleObject instance = new
SingleObject();
//make the constructor private so that this class cannot be instantiated
private SingleObject(){}
//Get the only object available
public static SingleObject getInstance()
{ return instance; }
public void showMessage()
{ System.out.println("Hello World!"); } }

5. public class SingletonPatternDemo {
public static void main(String[] args) {
//illegal construct
//Compile Time Error: The constructor SingleObject() is not visible
//SingleObject object = new SingleObject();
//Get the only object available
SingleObject object = SingleObject.getInstance();
//show the message
object.showMessage(); } }

6. Why Design Patterns? Simplifies object identification
Simplifies system decomposition
Proven & tested technique for problem solving
Improves speed & quality of
design / implementation
Can be adapted / refined for specific system under construction

7. Design Patterns Classification
Two categories
Class Scope:
Relationship between classes & subclasses statically defined at run-time
Object Scope:
Object relationships (what type?)
Can be manipulated at runtime (so what?)

9. Common Aspects of Object-Oriented Languages
Design pattern models are based and depend highly on the aspects of object-oriented languages.
Patterns-based programming doesn’t make much sense outside such languages.
Aspects of object-oriented languages like encapsulation, polymorphism, abstraction, and inheritance all extend their properties into patterns-based coding.
Patterns methodology is an extension of object-oriented methodology.

10. Encapsulation
Encapsulation is one of the most important aspects of object-oriented languages.
The rule of encapsulation is
one of keeping things private
masked inside the domain of an object, package, namespace, class, or interface
The rule of encapsulation allows only expected access to pieces of functionality.
The rule of encapsulation is used in almost every aspect of OOP
This rule allows us to build patterns like facades, proxies, bridges, and adapters.

11. Encapsulation
Encapsulation allows us to hide with an interface or class structure some functionality
we do not wish to be publicly or globally known.
Encapsulation allows us to define scope inside our programs, and helps us to define and group modules of logic.
Encapsulation provides ways to allow objects to communicate without that communication getting either too complex
Encapsulation provides rules of engagement between different code bases
It helps us decide what functionality can be known and what needs to be hidden.

12. Encapsulation Example
class CustomerPayment { public double PostPayment (int loanId, double payment) .....performs post of payment to customer account } public ArrayList GetAmortizedSchedule(int loanId) ...returns an amortization schedule in array

13. Encapsulation Example
The two methods in the code are visible as public.
We can assume that the CustomerPayment class has many other methods and code to help perform some of the functions of its two public methods
we cannot access them outside the class code
they are in effect invisible to any other classes in the code domain.
This gives us proper encapsulation of the class methods
Only the required methods to be accessed are allowed .
The method of encapsulation for this class
PostPayment()
GetAmortizedSchedule()
Thet can be accessed outside the class.

14. Polymorphism
Polymorphism is another important aspect of object-oriented programming.
The rule of polymorphism states that classes can be altered according to their state
in effect making them a different object based on values of attributes, type, or function.
We use polymorphism in almost every coding situation, especially patterns.
This rule gives us the power to use abstraction and inheritance,
It allows inherited members to change according to how they implement their base class.

15. Polymorphism
It also allows us to change a class’s purpose and function based on its current state.
Polymorphism helps interfaces change their implementation class type simply by allowing several different classes to use the same interface.
Polymorphic declarations of specific implementations of classes with a common base or interface are extremely common in object-oriented code

16. Polymorphism Example
if(IsAntiqueAuto) AntiqueAuto auto = new AntiqueAuto(); int cylinders = auto.Cylinders(); int numDoors = auto.NumberDoors(); int year = auto.Year(); string make = auto.Make(); string model = auto.Model(); }

17. Polymorphism Example
The first thing you need to answer is why do we want to change this code?
The answer might be one of portability: You wish to have many car types and pass the logic of creating them via the class itself, rather than via a logical Boolean statement.
Or you might wish to make sure all auto classes have the same methods so your code accessing the object always knows what to expect.

18. Polymorphism Example
In the code example below we can see an interface, IAuto, and below it some classes that we have modified to implement this interface.

19. Polymorphism Example
public interface IAuto { int Cylinders(); int NumberDoors(); int Year(); string Make(); string Model(); } class AntiqueAuto : IAuto.... class SportsCar : IAuto.... class Sedan : IAuto..... class SUV : IAuto.....
Each class also implements the interface’s method,
Each functioning in its own way, returning values according to the logic specific to the implemented methods on each class.

20. class AntiqueAuto : IAuto { public int Cylinders() { return 4; } public int NumberDoors() { return 3; } public int Year() { return 1905; } public string Make() { return "Ford"; } public string Model() { return "Model T"; } }

21. we instantiate the AntiqueAuto class as an instance of the IAuto interface and call each of the interface methods.
Each method returns a value from the methods implemented on the AntiqueAuto class
IAuto auto = new AntiqueAuto();
int cylinders = auto.Cylinders();
int numDoors = auto.NumberDoors();
int year = auto.Year();
string make = auto.Make();
string model = auto.Model();

22. Polymorphism Example
If we changed the implemented class to SportsCar or another auto type, the methods would return different values.
This is how polymorphism comes into play in class relationships.
By changing the class type for a common interface or abstraction, we can change the functionality and scope of the code without having to code if...then...else statements to accomplish the same thing.

23. Inheritance and Abstraction
Inheritance and abstraction are also very important features of object-oriented languages.
They provide a way to make polymorphic representations of objects and object relationships that can be managed at run time or compile time. .

24. Inheritance
Inheritance is the ability of one object to be derived by creating a new class instance from a parent or base class
overloading the constructor(s), methods, attributes of that parent object
implementing them in the instance.

25. Inheritance is important
Many times an object contains some base functionality that another object also needs
Instead of maintaining the same logic in two objects
They can share and even override or change this functionality by using a base or parent class.

26. Inheritance
The base or parent object should be defined in such a way that several common derived objects can use the same common functionality from the parent.
The parent should only contain functionality common to all its children

27. Abstraction
Abstraction is the actual method in which we use inheritance.
Abstraction is the ability to abstract into a base class some common functionality or design that is common to several implementation or instanced classes.
The difference between implementation and abstract classes is
Abstractions of classes cannot be instanced,
Implementations can be instanced
Abstraction and inheritance are both aspects of polymorphism
The reverse is also true

28. Collections of Objects
Another important aspect of object-oriented languages is how they deal with collections of objects.
The equals implementation for objects is an important aspect of dealing with objects inside a collection.
Languages like C#, VB.NET, and Java all use this method to help index and compare objects in collections.

29. THE CONCEPT OF PATTERNS Construction Architecture Patterns

30. The term 'pattern' appeals to the replicated similarity in a design
The first idea of using patterns was for building and proposed by the architect Christopher Alexander.
He found recurring themes in architecture, and captured them into descriptions
He called them patterns.
The term 'pattern' appeals to the replicated similarity in a design
The similarity makes room for variability and customization in each of the elements

31. Alexander defines: «Each pattern is a three part rule which express a relation between a certain context, a problem and a solution.
Each pattern is a relationship between
a certain context,
a certain system of forces which occurs repeatedly in that context
a certain spatial configuration which allows these forces to resolve themselves.
A pattern is an instruction and shows how this configuration can be used over and over again.
The pattern is a thing that happens in the world
The rule which tell us how to create that thing and when we must create it.

32. KitchenViewer Interface: An architectural pattern example
Wall
cabinet
menu 
Counter
display area
styles
Floor
cabinet
Modern
Classic
Antique
Arts & Crafts

33. KitchenViewer Example
Wall cabinets
Floor cabinets
Countertop
Modern
Classic
Antique
Arts & Crafts

34. Selecting Antique Style
Modern
Classic
Antique
Arts & Crafts

35. Specific Design Purposes for KitcherViewer
The procedure of rendering the various styles is basically the same regardless of the style .
The code is as follows:
Counter counter =new Counter();
draw (counters);
A single block of code that executes in several possible ways, depending on the context  Polymorphism
An application must construct a family of objects at runtime.
The design must enable choice among several families of styles

36. An Introduction to Design Pattens
Example Application: Without applying a Design Pattern
renderKitchen() method is used.
This code would have to be repeated for every style
The code that is supposed to be duplicated becomes different in different places.
Example Application: Applying a Design Pattern
renderKitchen(myStyle) method is used
KitchenViewer design purpose is implemented by applying Abstract Factory design pattern.

37. KitchenViewer Without Design Patterns
Client
renderKitchen()
Kitchen
WallCabinet
FloorCabinet
ModernWallCabinet
AntiqueWallCabinet
ModernFloorCabinet
AntiqueFloorCabinet

38. Without Applying Design Patterns
renderKitchen() method have to be repeated for every style
The method results in more prone-error and far less maintainable code
The code that is supposed to be duplicated becomes different in different places.
The result is repetitive and complicated .
It is inflexible, hard to prove correct, and hard to reuse

39. Applying Abstract Factory Design Pattern
The object will have responsibility for creating the kitchen .
Instead of creating the object directly (for example AntiqueWallCabinet objects), a parameterized version is used for renderKitchen()
At run time, the class of myStyle determines the version of getWallCabinet()executed.
The KitchenStyle method is introduced and called
This class has subclasses , and each support separate implementations of getWallCabinet() and getFloorCabinet()

40. The Abstract Factory Idea
KitchenStyle
getWallCabinet()
getFloorCabinet()
WallCabinet
FloorCabinet …
AntiqueWallCabinet …
AntiqueFloorCabinet
ModernKStyle
getWallCabinet()
getFloorCabinet()
AntiqueKStyle
getWallCabinet()
getFloorCabinet()
FloorCabinet getFloorCabinet()
{ return new ModernFloorCabinet(); }
FloorCabinet getFloorCabinet()
{ return new AntiqueFloorCabinet(); }

41. Processing the Abstract Factory Pattern:
KitchenViewer
KitchenViewer design purpose is implemented by applying Abstract Factory design pattern.
AntiqueWallCabinet objects are not created directly.
A parameterized version of renderKitchen() delegates their creation such as the following:
new AntiqueWallCabinet();//applies only to antique style.
myStyle.getWallCabinet(); //applies to the style chosen at run time. .

42. Processing the Abstract Factory Pattern: KitchenViewer
At run time , the class of myStyle determines the version of getWallCabinet() and produces the appropriate kind of wall cabinet

43. Processing the Abstract Factory Pattern:
KitchenViewer
To carry out this process, a new class KitchenStyle is introduced.
KitchenStyle supports the methods getWallCabinet(), getFloorCabinet() and so on.
KitchenStyle have subclasses ModernStyle, AntiqueStyle.

44. Due to the polymorphism, executing myStyle.getFloorCabinet()
has differently effects when myStyle is an object of ModernKStyle versus an object of AntiqueKStyle.
Client code references Kitchen,
KitchenStyle,WallCabinet and FloorCabinet, but does not appear in the client code.

45. Abstract Factory Design Pattern Applied to KitchenViewer
Client
renderKitchen( KitchenStyle )
Abstract Factory Design Pattern Applied to KitchenViewer
KitchenStyle
getWallCabinet()
getFloorCabinet()
Kitchen
getWallCabinet()
getFloorcabinet()
WallCabinet
FloorCabinet
ModernWallCabinet
ModernKStyle
getWallCabinet()
getFloorCabinet()
AntiqueWallCabinet
AntiqueKStyle
getWallCabinet()
getFloorCabinet()
ModernFloorCabinet
AntiqueFloorCabinet

46. Abstract Factory Design Pattern
Properties
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
A hierarchy that encapsulates: many possible platforms, and the construction of a suite of products.
The new operator considered harmful
Problem
If an application is to be portable, it needs to encapsulate platform dependencies.
These platforms might include: windowing system, operating system, database…

47. Abstract Factory Pattern
General Structure:
Abstract Factory Pattern
The Abstract Factory defines a Factory Method per product.
Each Factory Method encapsulates the new operator and the concrete, platform-specific, product classes.
Each platform is then modeled with a Factory derived class.

48. The Factory Method Pattern
Product
Defines the interface for the type of objects the factory method creates
ConcreteProduct
Implements the Product interface
Creator
Declares the factory method, which returns an object of type Product
ConcreteCreator
Overrides the factory method to return an instance of a ConcreteProduct
Creator relies on its subclasses to implement the factory method so that it returns an instance of the appropriate ConcreteProduct

49. The Factory Method Pattern
Code is made more flexible and reusable by the elimination of instantiation of application-specific classes
Code deals only with the interface of the Product class and can work with any ConcreteProduct class that supports this interface
Clients might have to subclass the Creator class just to instantiate a particular ConcreteProduct
Creator can be abstract or concrete
Should the factory method be able to create multiple kinds of products?
If so, then the factory method has a parameter (possibly used in an if-else!) to decide what object to create

50. Factory Design Pattern
Online bookstores that can choose different book distributors to ship the books to the customers
Both BookStoreA and BookStoreB choose which distributor (EastCoastDistributor or MidWestDistributor or WestCoastDistributor) to use based on the location of the customer.
This logic is in each bookstore's GetDistributor method.

51. Abstract Factory Pattern
The abstract factory design pattern is an extension of the factory method pattern,
The abstract factory pattern allows to create objects without being concerned about the actual class of the objects being produced.
The abstract factory pattern extends the factory method pattern by allowing more types of objects to be produced.

52. Extension of GetDistributor() Method to Abstract Factory Pattern
We can extend GetDistributor() method by
Adding another product that the factories can produce.
In this example, we will add Advertisers that help the bookstores advertise their stores online.
Each bookstore can then choose their own distributors and advertisers inside their own GetDistributor and GetAdvertiser method.

53. public void Advertise(IBookStore s){
IAdverister a = s.GetAdvertiser();
a.Advertise(); }

54. This allows to have client code (calling code) such as:
public void Advertise(IBookStore s) {
IAdverister a = s.GetAdvertiser();
a.Advertise(); }
Regardless if you pass in BookStoreA or BookStoreB into the method, this client code does not need to be changed since it will get the correct advertiser automatically using the internal logics within the factories.
It is the factories (BookStoreA and BookStoreB) that determines which advertiser to produce.
The same goes for choosing which book distributor to produce

55. Abstract Factory Design Pattern

56. The Benefit of the Abstract Factory Pattern
The benefit of the Abstract Factory pattern is that it allows you to create a groups of products (the distributors and the advertisers) without having to know the actual class of the product being produced.
The result is that you can have client code that does not need to be changed when the internal logic of the factories changed.
We can change the types of the products (the distributors and the advertisers) by changing the code in the factories (the bookstores) without changing the client code

57. public enum CustomerLocation { EastCoast, WestCoast }
class Program {
static void Main(string[] args)
IBookStore storeA = new
BookStoreA(CustomerLocation.EastCoast);
Console.WriteLine("Book Store A with a customer from East Coast:");
ShipBook(storeA);
Advertise(storeA);
IBookStore storeB = new
BookStoreB(CustomerLocation.WestCoast);
Console.WriteLine("Book Store B with a customer from West Coast:");
ShipBook(storeB);
Advertise(storeB); }

58. //. client code that does not need to be changed
//**** client code that does not need to be changed *** private static void ShipBook(IBookStore s)
{ IDistributor d = s.GetDistributor();
d.ShipBook(); }
//**** client code that does not need to be changed *** private static void Advertise(IBookStore s)
{ IAdvertiser a = s.GetAdvertiser();
a.Advertise();

59. public interface IBookStore { IDistributor GetDistributor();
//the factory
public interface IBookStore {
IDistributor GetDistributor();
IAdvertiser GetAdvertiser(); }
//concrete factory
public class BookStoreA : IBookStore {
private CustomerLocation location;
public BookStoreA(CustomerLocation location)
this.location = location; }

60. IDistributor IBookStore.GetDistributor(){
//internal logic on which distributor to return /
/*** logic can be changed without changing the client code **** switch (location)
case CustomerLocation.EastCoast:
return new EastCoastDistributor();
case CustomerLocation.WestCoast:
return new WestCoastDistributor(); }
return null;

61. IAdvertiser IBookStore.GetAdvertiser(){
//internal logic on which distributor to return
//*** logic can be changed without changing the client code **** switch (location)
case CustomerLocation.EastCoast:
return new RedAdvertiser();
case CustomerLocation.WestCoast:
return new BlueAdvertiser(); }
return null;
} //end of factory class

62. { private CustomerLocation location;
public class BookStoreB : IBookStore //concrete factory
{ private CustomerLocation location;
public BookStoreB(CustomerLocation location)
{ this.location = location; }
IDistributor IBookStore.GetDistributor()
{ switch (location)
{ case CustomerLocation.EastCoast:
return new EastCoastDistributor();
case CustomerLocation.WestCoast:
return new WestCoastDistributor();
} return null; }
IAdvertiser IBookStore.GetAdvertiser()
{switch (location)
return new BlueAdvertiser();
return new RedAdvertiser();
} return null; } }

63. //the product
public interface IDistributor {
void ShipBook(); }
//concrete product
public class EastCoastDistributor : Idistributor {
void IDistributor.ShipBook()
{ Console.WriteLine("Book shipped by East Coast Distributor"); } }
public class WestCoastDistributor : IDistributor
{ Console.WriteLine("Book shipped by West Coast Distributor"); } }

64. public interface IAdvertiser //the product{
void Advertise(); }
public class RedAdvertiser : IAdvertiser //concrete product
void IAdvertiser.Advertise()
{ Console.WriteLine("Advertised by RedAdvertiser"); }
public class BlueAdvertiser : IAdvertiser //concrete product
void IAdvertiser.Advertise()
{ Console.WriteLine("Advertised by BlueAdvertiser"); }