SOFTWARE DESIGNING AND

NEED OF DESIGN PATTERNS

Delivered By : Jayant V Mhatre

Date : 2nd Dec 2011.

Programming tasks originate from the desire to find business solution to a particular problem. Software Design Has 3 Phases

1. Analysis Phase.2. Design Phase.3. Implementation Phase.

NEED OF SOFTWARE

Understand business requirement. Business Analyst has major role . Outcome of Analysis Phase :

Documentation of Business requirement which Includes

1. Business Requirement Document(BRD)

2.System Requirement Specification

document (SRD).

3. Use Case Diagrams.

** These Documents should be understand by both Programmer and Client.

** Analysis only describes what is to be done and not how it to be done.

ANALYSIS PHASE

Mainly Consist of Identifying :

1. Classes

2. Responsibilities of Classes.

3. Relationship Among Classes.

Requirement : Business Document generated in Analysis phase.

** Programming Language is not essential in Design Phase it is general for all (exa:java,.net).

DESIGN PHASE (OOL)

Identify Dependency :

Good Software design requires that dependency should be minimized .

Association :

Generalization Relationship :

Is a Relation

Aggregation :

Takes place if object of one class contain object of another class .

( has a relation)

Composition (Stronger Aggregation):

Outcome of Design Phase :1. ERD Diagrams.

2. UML Diagrams.

3. Class Diagrams

4. Sequence Diagrams.

5. State Diagrams.

RELATIONSHIP AMONG CLASSES.

Coding. Testing. Integrations of modules. Design is implemented.

IMPLEMENTATION PHASE

Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987.

For Example : Houses near to see shore, Or houses in Cold areas. Have same patterns to suit to the environment situations .

Thousands of people goes under a different ways and the best way gets consider as Pattern.

Same Concepts are used in Design Patterns

HISTORY OF DESIGN PATTERNS

General Definition : Design Patterns are standard solutions to solve problems of same type.

Standard Definition : Design patterns are Recurring solutions to software design problems you find again and again in real world applications.

A pattern presents Proven advice in a standard format.

Gives standard rules of coding.

D.P. are used for Code to be more Usable, more Maintainable, can used in future to changes with minimum effort.

WHAT IS DESIGN PATTERNS.

D.P. are about design and integration of objects. As well as D.P. are providing Communication Platform reusable solutions to commonly encountered programming challenges/ problems.

WHAT IS DESIGN PATTERNS.

First book on Design Patterns was written by 4 Authors Gamma Erich; Richard Helm, Ralph Johnson, and John Vlissides in (1995) .

Which is known as Gang of Four.

They Described Total 23 Patterns. Which are known as Foundation patterns. Today we have more than 100 patterns.

These 23 patterns can be categorized in 3 parts.

1. Structural Patterns.

2. Creational Patterns.

3. Behavioral Patterns.

DESIGN PATTERNS

These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality. Adapter:-Match interfaces of different classes . • Bridge:-Separates an object’s abstraction from its implementation. • Composite:-A tree structure of simple and composite objects. • Decorator:-Add responsibilities to objects dynamically. • Façade:-A single class that represents an entire subsystem.• Flyweight:-A fine-grained instance used for efficient sharing. • Proxy:-An object representing another object.

STRUCTURAL PATTERNS.

Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.

Abstract Factory groups object factories that have a common theme.

Builder constructs complex objects by separating construction and representation.

Factory Method creates objects without specifying the exact class to create.

Prototype creates objects by cloning an existing object.

Singleton restricts object creation for a class to only one instance.

CREATIONAL PATTERNS.

Most of these design patterns are specifically concerned with communication between objects.

• Mediator:-Defines simplified communication between classes.• Memento:-Capture and restore an object's internal state. • Interpreter:- A way to include language elements in a program.• Iterator:-Sequentially access the elements of a collection. • Chain of Resp: - A way of passing a request between a chain of objects.• Command:-Encapsulate a command request as an object. • State:-Alter an object's behavior when its state changes. • Strategy:-Encapsulates an algorithm inside a class. • Observer: - A way of notifying change to a number of classes. • Template Method:-Defer the exact steps of an algorithm to a subclass. • Visitor:-Defines a new operation to a class without change.

BEHAVIORAL PATTERNS.

Factory pattern is one of the types of creational patterns factory pattern is meant to centralize creation of objects.

Consider a general example :

if (intInvoiceType == 1)

{

objinv = new clsInvoiceWithHeader();

}

else if (intInvoiceType == 2)

{

objinv = new clsInvoiceWithOutHeaders();

}

FACTORY PATTERN

First we have lots of ‘new’ keyword scattered in the client. In other ways the client is loaded with lot of object creational activities which can make the client logic very complicated. Second issue is that the client needs to be aware of all types of invoices. So if we are adding one more invoice class type called as ‘InvoiceWithFooter’ we need to reference the new class in the client and recompile the client also.

So we will create ‘Factory Pattern’ which has two concrete classes ‘ClsInvoiceWithHeader’ and ‘ClsInvoiceWithOutHeader’.

The first issue was that these classes are in direct contact with client which leads to lot of ‘new’ keyword scattered in the client code. This is removed by introducing a new class ‘ClsFactoryInvoice’ which does all the creation of objects. The second issue was that the client code is aware of both the concrete classes i.e. ‘ClsInvoiceWithHeader’ and ‘ClsInvoiceWithOutHeader’. This leads to recompiling of the client code when we add new invoice types. For instance if we add ‘ClsInvoiceWithFooter’ client code needs to be changed and recompiled accordingly. To remove this issue we have introduced a common interface ‘IInvoice’. Both the concrete classes ‘ClsInvoiceWithHeader’ and ‘ClsInvoiceWithOutHeader’ inherit and implement the ‘IInvoice’ interface.

The client references only the ‘IInvoice’ interface which results in zero connection between client and the concrete classes ( ‘ClsInvoiceWithHeader’ and ‘ClsInvoiceWithOutHeader’). So now if we add new concrete invoice class we do not need to change any thing at the client side.  In one line the creation of objects is taken care by ‘ClsFactoryInvoice’ and the client disconnection from the concrete classes is taken care by ‘IInvoice’ interface.

http://www.dotnetfunda.com/articles/article130.aspx#Canyouexplainfactorypattern.

http://msdn.microsoft.com/en-us/magazine/cc188707.aspx

http://userpages.umbc.edu/~tarr/dp/lectures/Factory.pdf

http://www.codeproject.com/KB/architecture/FactoryPattBasics.aspx

http://www.developerfusion.com/article/8307/aspnet-patterns-every-developer-should-

It will check how less code is manipulate in future. Try to have more loose Coupling of classes or objects is there. enable large scale reuse of S/WHelps in improve developer communicationcapture expert knowledge and design trade-offs and make expertise widely available

BENEFITS OF DESIGN PATTERNS

. Complex in nature Do not lead to direct code reuse. They consume more memory because of generalized format they are written, to store any kind of data .

DRAWBACKS OF DESIGN PATTERNS

THANK YOU.

THANK YOU.