Design Pattern & GRASP.

Patterns come out naturally and is completely on-demand as per the scenario.

Difference between Design Pattern VS Architecture Pattern VS Architecture Style

Design pattern is at code level. It helps you to understand OOP problems easily. Ex: - Factory
Pattern, Singleton etc.

Architecture Pattern is a high level diagram like MVC, MVP, and MVVM. Like block level diagrams

Architecture Principles are just one liners or principles. Like REST, SOA is an Architecture Style

Design Pattern: Design patterns are time tested solutions for Software Architecture problems.
Design patterns are time tested practices for OOP problems. Design patterns are documented tried
and tested solutions for recurring problems in a given context. It is documented best practices for
software architecture.

Every projects have 3 architectural issues Creational, Structural and Behavioural issues which can be
sorted out by using the below architecture patterns:

1) Creational Patterns: helps us to centralize the creation of objects at one place or class.
Hence minimizing the complicated code at client side and make them loose coupling.
Ex: client is creating, using and disposing lots of objects in the projects. This leads to lots of
complication in code and very tight coupling in client and main objects. To reduce this we
have Creational Patterns.
2) Structural Patterns: Sometimes we want to change the architecture or relationship of the
project but don’t want the project affected.
Ex: Suppose Customer class has customerphone in it. This shows one to many relationship
between classes. Now client want to move the customerphone class away from customer
class. Want to make it independent so both class will operate independent. This is Structural
change. And we want this structural doesn’t affect the project. That is where structural
pattern helps to make classes to work seamlessly.
3) Behavioural Patterns: Sometimes in the project architecture you want to change the
behaviour of the class and don’t want to affect other classes in the project.
Ex: we have clsinvoice class which is having the logic of some taxes in it. In near future we
want to make some additional taxes which doesn’t has to take anything from normal taxes
to implement on the clsinvoice class. This is behavioural change in clsinvoice. So this can be
solved by Behavioural patterns.
 Factory pattern: It falls in Creational category. It’s means to construct or create
something. It means to create object.

Why we need Factory pattern

If(invoiceType=1)
{
Objinv= new clsInvoiceWithHeader();
}
Else if(invoiceType=2)
{
Objinv= new clsInvoiceWithoutHeader();
}

So 2 big issues with above code:

At client side lots of new keyword and client knows what kind of functions a concrete class owns.

If in near future we create a new method in class then again i have to change in concrete class and i
have to inform client also about the new method and then again recompile the class.

So we can use Factory pattern to sort out the above issues:

ISSUE 1 Lots of new keyword

We will implement a Factory invoice class which will take invoicetype from client and create the
relevant object

public class clsFactoryInvoice

{
static public IInvoice getInvoice(int intInvoiceType)
{
IInvoice objinv;
if (intInvoiceType == 1)
{
objinv = new clsInvoiceWithHeader();
}
else if (intInvoiceType == 2)
{
objinv = new clsInvoiceWithOutHeaders();
}
else
{
return null;
}
return objinv;
}
}

ISSUE 2 Client knowing Class methods

We will create an interface and implement on concrete classes. So the interface will stand between
client and concrete classes. So now if i will add a new class then client would not mind.

Client would not be able to know what my concrete class owns.

Now the flow of creation object is as below:

Client will call factory class for object creation and then create the relevant object and give object
reference to interface and then the method of that concrete class will be called.

Abstract Factory Pattern : is an extension of Factory pattern. It expands on the basic

factory pattern.

Abstract factory patterns helps us to unite similar factory pattern classes into one unified interface.

Abstract factory helps us to bring uniformity between related factory patterns which lead to more
simplified interface to client.

Abstract factory pattern is rarely used pattern because if we properly create our Factory pattern
then we don’t need to create Abstract Factory pattern. If Factory pattern is not present then we
can’t implement Abstract factory pattern. If the number of factory pattern increases then we create
abstract factory pattern to bring the uniformity between concrete classes and bring down the client
code complexity.

When you found your application going large and found common things in factory classes then you
can create an abstract factory pattern.
Singleton Pattern: It falls in creational category.
There are situations where we want only one instance of the object to be created and shared
between clients. Like global data.

No client can create an instance from outside. Only it can be created by itself and once it created all
the manipulation will be done on that copy which would be shared among clients.

Points to create singleton pattern.

 To create singleton pattern we need to make our constructor as private.
 Define the instances and methods as static.

public class clsSingleTon

{
public static int intCounter;
private clsSingleTon()
{
// This is a private constructor
}
public static void Hit()
{
intCounter++;
}
public static int getTotalHits()
{
return intCounter;
}
}

FACADE Pattern: It falls in structural category.

It sits on the top of group of subsystems and allow them to communicate in a unified manner.

Ex: To place the order i need to perform 3 steps like get the product detail, after that pay the
amount online and then print the invoice.
  So facade is all about consolidating and achieving some kind of functionality by aggregating
some type of functionality.
 With facade you are showing a simplified UI to the user. Rather than user call these 3
subsystems separately and making user interface complicated he can present the user with a
Facade system where user just need to interact with only one method.

OBSERVER Pattern: It falls in behavioural categories.

Observer pattern helps us to communicate between parent class and its associated or dependent
classes.
Ex: Suppose you have an application or component which want to notify or broadcast message to
different observers about the error, then go for Observer pattern in your project architecture but
don’t rush for it without thinking. First see your project scenario if you can achieve the same thing
with your custom code then go for it o/w go for observer pattern.

In this pattern you can add/remove the observers as per client requirement.

IOC(Inversion Of Control) Pattern: Its a pro

Problem in the below code:

 Customer class controls the creation of address object.

 Address class is directly referenced in customer class which leads to tight coupling between
address and customer object.
 If in near future there is any changes in address class like office address and home address,
then we need to make changes in customer as well because there is huge tight coupling
between customer and address class

Here the creation control is with Customer class but what IOC says

In DI(Dependency Injection) the creation of control is inverted to somewhere else.

Interface based DI and Service Locator are rarely used pattern to implement DI.