Sofwear deasign and need of design pattern
Upcoming SlideShare
Loading in...5

Like this? Share it with your network

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 16 13 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. SOFTWARE DESIGNING AND NEED OF DESIGN PATTERNSDelivered By : Jayant V MhatreDate : 2nd Dec 2011.
  • 2. NEED OF SOFTWARE Programming tasks originate from thedesire to find business solution to a particularproblem. 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 bothProgrammer and Client.** Analysis only describes what is to be done and not howit 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 inAnalysis phase.** Programming Language is not essential in DesignPhase 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 Diagrams4. 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 standardsolutions to solve problems of same type. Standard Definition : Design patterns are Recurringsolutions to software design problems you find againand again in real world applications. A pattern presents Proven advice in a standardformat. Gives standard rules of coding.D.P. are used for Code to be more Usable, moreMaintainable, can used in future to changes withminimum 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 encounteredprogramming challenges/ problems.
  • 10. DESIGN PATTERNS First book on Design Patterns was written by 4 AuthorsGamma Erich; Richard Helm, Ralph Johnson, and JohnVlissides in (1995) .Which is known as Gang of Four. They Described Total 23 Patterns. Which are known asFoundation patterns. Today we have more than 100patterns. 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. Theyuse inheritance to compose interfaces and defineways to compose objects to obtain new functionality. Adapter:-Match interfaces of different classes .• Bridge:-Separates an object’s abstraction from itsimplementation.• Composite:-A tree structure of simple and compositeobjects.• Decorator:-Add responsibilities to objects dynamically.• Façade:-A single class that represents an entiresubsystem.• Flyweight:-A fine-grained instance used for efficientsharing.• Proxy:-An object representing another object.
  • 12. CREATIONAL PATTERNS.Creational patterns are ones that create objects foryou, rather than having you instantiate objectsdirectly. This gives your program more flexibility indeciding which objects need to be created for a givencase.Abstract Factory groups object factories that have acommon theme.Builder constructs complex objects by separatingconstruction and representation.Factory Method creates objects without specifying theexact class to create.Prototype creates objects by cloning an existingobject.Singleton restricts object creation for a class to onlyone instance.
  • 13. BEHAVIORAL PATTERNS.Most of these design patterns are specifically concernedwith communication between objects.• Mediator:-Defines simplified communication betweenclasses.• Memento:-Capture and restore an objects internal state.• Interpreter:- A way to include language elements in aprogram.• Iterator:-Sequentially access the elements of a collection.• Chain of Resp: - A way of passing a request between achain of objects.• Command:-Encapsulate a command request as an object.• State:-Alter an objects behavior when its state changes.• Strategy:-Encapsulates an algorithm inside a class.• Observer: - A way of notifying change to a number ofclasses.• Template Method:-Defer the exact steps of an algorithm toa 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 theclient. In other ways the client is loaded with lot of objectcreational activities which can make the client logic verycomplicated. Second issue is that the client needs to be aware of alltypes of invoices. So if we are adding one more invoiceclass type called as ‘InvoiceWithFooter’ we need toreference the new class in the client and recompile theclient also.
  • 16.  So we will create ‘Factory Pattern’ which has twoconcrete classes ‘ClsInvoiceWithHeader’ and‘ClsInvoiceWithOutHeader’. The first issue was that these classes are in directcontact with client which leads to lot of ‘new’ keywordscattered in the client code. This is removed by introducinga new class ‘ClsFactoryInvoice’ which does all the creationof objects. The second issue was that the client code is aware ofboth the concrete classes i.e. ‘ClsInvoiceWithHeader’ and‘ClsInvoiceWithOutHeader’.This leads to recompiling of the client code when we addnew invoice types. For instance if we add‘ClsInvoiceWithFooter’ client code needs to be changedand recompiled accordingly. To remove this issue we have introduced a commoninterface ‘IInvoice’. Both the concrete classes‘ClsInvoiceWithHeader’ and ‘ClsInvoiceWithOutHeader’inherit and implement the ‘IInvoice’ interface.
  • 17.  The client references only the ‘IInvoice’ interface whichresults in zero connection between client and the concreteclasses ( ‘ClsInvoiceWithHeader’ and‘ClsInvoiceWithOutHeader’). So now if we add newconcrete invoice class we do not need to change any thingat the client side. In one line the creation of objects is taken care by‘ClsFactoryInvoice’ and the client disconnection from theconcrete classes is taken care by ‘IInvoice’ interface.
  • 18.
  • 19. BENEFITS OF DESIGN PATTERNS It will check how less code is manipulate in future. Try to have more loose Coupling of classes or objects isthere. enable large scale reuse of S/WHelps in improve developer communicationcaptureexpert knowledge and design trade-offs andmake expertise widely available
  • 20. DRAWBACKS OF DESIGN PATTERNS . Complex in nature Do not lead to direct code reuse. They consume more memory because of generalizedformat they are written, to store any kind of data .
  • 21. THANK YOU.
  • 22. THANK YOU.