This document discusses software design and the need for design patterns. It covers the three phases of software design: analysis, design, and implementation. It then discusses what design patterns are, providing the definition that they are standard solutions to common programming problems. The document outlines the three main categories of design patterns: structural, creational, and behavioral. It provides examples like the factory pattern, explaining how it works to reduce dependencies and improve flexibility. In summary, the document introduces software design processes and argues that using design patterns provides benefits like improved code reuse and developer communication.

1. SOFTWARE DESIGNING
AND
NEED OF
DESIGN PATTERNS
Delivered By : Jayant V Mhatre
Date : 2nd Dec 2011.

2. NEED OF SOFTWARE
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.

3. ANALYSIS PHASE
 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.

4. DESIGN PHASE (OOL)
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).

5. RELATIONSHIP AMONG CLASSES.
 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.

6. IMPLEMENTATION PHASE
 Coding.
 Testing.
 Integrations of modules.
 Design is implemented.

7. HISTORY OF DESIGN PATTERNS
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

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

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

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

11. STRUCTURAL 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.

12. CREATIONAL 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.

13. BEHAVIORAL 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.

14. FACTORY PATTERN
 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();
}

15.  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.

16.  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.

17.  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.

21. http://www.dotnetfunda.com/articles/article130.aspx#C
anyouexplainfactorypattern.
http://msdn.microsoft.com/en-
us/magazine/cc188707.aspx
http://userpages.umbc.edu/~tarr/dp/lectures/Factory.p
df
http://www.codeproject.com/KB/architecture/FactoryPa
ttBasics.aspx
http://www.developerfusion.com/article/8307/aspnet-
patterns-every-developer-should-

22. BENEFITS OF DESIGN PATTERNS
 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/W
Helps in improve developer communication
captureexpert knowledge and design trade-offs and
make expertise widely available

23. DRAWBACKS 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 .

24. THANK YOU.

25. THANK YOU.