• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Prophecy Of Design Patterns
 

Prophecy Of Design Patterns

on

  • 395 views

A Tech presentation for the Tech Savvy\'s who are interested in Application Architecture and Designing.

A Tech presentation for the Tech Savvy\'s who are interested in Application Architecture and Designing.

Statistics

Views

Total Views
395
Views on SlideShare
393
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Prophecy Of Design Patterns Prophecy Of Design Patterns Presentation Transcript

    • Prophecy of Design PatternsSep 11th,12th & 13th 2012 By Pradeep Kothiyal
    •  What are design patterns? Design Patterns are:  Recurring solutions to software design problems you find again and again in real-world application development.  A general reusable solution to a commonly occurring problem in software design. - wiki  It is a description or template for how to solve a problem that can be used in many different situations.  Are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges.  GoF Patterns are considered the foundation of all design patterns.
    •  What are design patterns? Design Patterns are:  NOT a finished design that can be transformed directly in code.  Object-oriented design patterns shows relationships and interactions between classes or objects without specifying the final application classes or objects that are involved.  Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns[larger in scope], usually describing an overall pattern followed by an entire system.  NOT ALL software patterns are design patterns. Ex: Algorithms solve computational problems rather than software design problems.
    •  GoF’s contributions in design pattern  Gang of Four was a team of four members: Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. (L-R) Ralph, Erich, Richard and John
    •  GoF’s contributions in design pattern  Profiles:  Erich Gamma: Technical Director at Software Technology Center of OTI at Zurich. Currently working on the IBM Rational Jazz project  Richard Helm: With Boston Consulting Group(BCG) in Sydney, OZ.  Ralph Johnson: Working on the PatternStoriesWiki and promoting the OnLineComputerMuseum. Research Associate Professor in the Department of Computer Science at the University of Illinois at Urbana-Champaign  John Vlissides: Was researcher at IBMs T.J. Watson Research Center. All 23 patterns has been designed by GoF. There are more then 300 design patterns in developer community, which are derived from these 23 patterns.
    •  Three broad visions:  Creational Patterns: are design patterns that deals with Object Creation Mechanism, trying to create objects in a manner suitable to the situation. Ex: Abstract Factory, Factory Method etc.  Structural Patterns: ease the design by identifying a simple way to realize relationship between entities. Ex: Façade, Adapter, Proxy etc.  Behavioral Patterns: Identify common communication patterns between objects and realize these patterns, thus increases flexibility in carrying out this communications. Ex: Observer, Iterator, Command etc.
    •  Commonly used patterns: S No Category Pattern Usage 1 Creational Factory Method* 2 Abstract Factory 3 Singleton 4 Structural Adapter 5 Composite 6 Façade* 7 Behavioral Command 8 Iterator 9 Observer* 10 Strategy *sample examples
    •  Factory Method: [Creational Patterns] Definition: Define an interface for creating an object, but let subclasses decide which class to instantiate. Lets a class defer instantiation to subclasses. Participants: Product (Page) : defines the interface of objects the factory method creates. ConcreteProduct (SkillsPage, EducationPage, ExperiencePage): implements the Product interface Creator (Document) : declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object. may call the factory method to create a Product object. ConcreteCreator (Report, Resume): overrides the factory method to return an instance of a ConcreteProduct.
    •  Factory Method: [Creational Patterns] UML Notification: Code Example
    •  Abstract Factory: [Creational Patterns] Definition: Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Participants: AbstractFactory (ContinentFactory): declares an interface for operations that create abstract products. ConcreteFactory (AfricaFactory, AmericaFactory): implements the operations to create concrete product objects. AbstractProduct (Herbivore, Carnivore): declares an interface for a type of product object. Product (Wildebeest, Lion, Bison, Wolf): defines a product object to be created by the corresponding concrete factory. implements the AbstractProduct interface. Client (AnimalWorld): uses interfaces declared by AbstractFactory and AbstractProduct classes.
    •  Abstract Factory: [Creational Patterns] UML Notification:
    •  Singleton: [Creational Patterns] Definition: Ensure a class has only one instance and provide a global point of access to it. Participants: Singleton (LoadBalancer): defines an Instance operation that lets clients access its unique instance. Instance is a class operation. responsible for creating and maintaining its own unique instance. UML Notification:
    •  Adapter: [Structural Patterns] Definition: Convert the interface of a class into another interface clients expect. Lets classes work together that couldnt otherwise because of incompatible interfaces. Participants: Target (ChemicalCompound): defines the domain-specific interface that Client uses. Adapter (Compound): adapts the interface Adaptee to the Target interface. Adaptee (ChemicalDatabank): defines an existing interface that needs adapting. Client (AdapterApp): collaborates with objects conforming to the Target interface.
    •  Adapter: [Structural Patterns] UML Notification:
    •  Composite: [Structural Patterns] Definition: Compose objects into tree structures to represent part- whole hierarchies. Lets clients treat individual objects and compositions of objects uniformly. Participants: Component (DrawingElement): declares the interface for objects in the composition. implements default behavior for the interface common to all classes, as appropriate. declares an interface for accessing and managing its child components. (optional) defines an interface for accessing a components parent in the recursive structure, and implements it if thats appropriate.
    •  Composite: [Structural Patterns] Participants: Leaf (PrimitiveElement): represents leaf objects in the composition. A leaf has no children. defines behavior for primitive objects in the composition. Composite (CompositeElement): defines behavior for components having children. stores child components. implements child-related operations in the Component interface. Client (CompositeApp):manipulates objects in the composition through the Component interface.
    •  Composite: [Structural Patterns] UML Notification:
    •  Facade: [Structural Patterns] Definition: Provide a unified interface to a set of interfaces in a subsystem. defines a higher-level interface that makes the subsystem easier to use. Participants: Façade (MortgageApplication): knows which subsystem classes are responsible for a request. delegates client requests to appropriate subsystem objects Subsystem classes (Bank,Credit,Loan) implement subsystem functionality. handle work assigned by the Facade object. have no knowledge of the facade and keep no reference to it
    •  Facade: [Structural Patterns] UML Notification: Code Example
    •  Command: [Behavioral Patterns] Definition: Encapsulate a request as an object. thereby letting parameterize clients with different requests, queue or log requests, and support undoable operations Participants: Command (Command): declares an interface for executing an operation. ConcreteCommand (CalculatorCommand): defines a binding between a Receiver object and an action. implements Execute by invoking the corresponding operation(s) on Receiver. Client (CommandApp) : creates a ConcreteCommand object and sets its receiver . Invoker (User): asks the command to carry out the request. Receiver (Calculator): knows how to perform the operations associated with carrying out the request.
    •  Command: [Behavioral Patterns] UML Notification:
    •  Iterator: [Behavioral Patterns] Definition: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. Participants: Iterator (AbstractIterator): defines an interface for accessing and traversing elements. ConcreteIterator (Iterator): implements the Iterator interface. keeps track of the current position in the traversal of the aggregate. Aggregate (AbstractCollection): defines an interface for creating an Iterator object. ConcreteAggregate (Collection): implements the Iterator creation interface to return an instance of the proper ConcreteIterator.
    •  Iterator: [Behavioral Patterns] UML Notification:
    •  Observer: [Behavioral Patterns] Definition: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Participants: Subject (Stock): knows its observers. Any number of Observer objects may observe a subject provides an interface for attaching and detaching Observer objects. ConcreteSubject (IBM): stores state of interest to ConcreteObserver. sends a notification to its observers when its state changes. Observer (Iinvestor): defines an updating interface for objects that should be notified of changes in a subject. ConcreteObserver (Investor): maintains a reference to a ConcreteSubject object.
    •  Observer: [Behavioral Patterns] Participants: ConcreteObserver (Investor): stores state that should stay consistent with the subjects. implements the Observer updating interface to keep its state consistent with the subjects.
    •  Observer: [Behavioral Patterns] UML Notification: Code Example
    •  Strategy: [Behavioral Patterns] Definition: Define a family of algorithms, encapsulate each one, and make them interchangeable. Lets the algorithm vary independently from clients that use it. Participants: Strategy (SortStrategy): declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy. ConcreteStrategy (QuickSort, ShellSort, MergeSort) : implements the algorithm using the Strategy interface. Context (SortedList) : is configured with a ConcreteStrategy object . maintains a reference to a Strategy object. may define an interface that lets Strategy access its data.
    •  Strategy: [Behavioral Patterns] UML Notification:
    •  Comparison tally of design patterns: S No Category Pattern Usage 1 Creational Abstract Factory 2 Builder 3 Factory Method 4 Prototype 5 Singleton 6 Structural Adapter 7 Bridge 8 Composite 9 Decorator 10 Facade 11 Flyweight 12 Proxy
    •  Comparison tally of design patterns: S No Category Pattern Usage 13 Behavioral Chain of Responsibility 14 Command 15 Interpretor 16 Iterator 17 Mediator 18 Memento 19 Observer 20 State 21 Strategy 22 Template Method 23 Visitor
    •  Observer Design Pattern: Optimizing PerformanceRequirements: Each Order is associated with one Customer and one SalesPerson. Each Order includes various OrderDetail transactions. [Relationship One to Many]
    •  Observer Design Pattern: Optimizing PerformanceRequirements:user wants to view Report or Dashboard including total sales amount for each product, totalsold amount each sales person sells, and total payment amount each customer pays.
    •  Observer Design Pattern: Optimizing PerformanceSolution:Making sum once, storing it in the database.Customer: Add field “TotalPaymentAmount”Product: Add field “TotalSalesAmount”SalesPerson: Add field “TotalSoldAmount”
    •  Observer Design Pattern: Optimizing PerformanceSolution: when SalesPerson updates Order data, system updates 3 total fields too. This gives ahint about Subscriber-Publisher Model(Observer Pattern).
    •  Observer Design Pattern: Optimizing PerformanceObserver Design Pattern:defines a one-to-many dependency between objects so that when one object changes state,all its dependents are notified and updated automatically.
    •  Design Pattern: Real world challenges• What kind of evidence do we need to have to know that a patternis of general use in design?• What are the barriers for making a pattern language a useful toolfor the broader community of educators and educationalresearchers?• As the pattern approach becomes more successful, how can weensure that pattern authors build on each other’s work, fostering aculture of knowledge accumulation?• How is the pattern approach related to other means of knowledgesharing?Ref: http://patternlanguagenetwork.myxwiki.org/xwiki/bin/view/Groups.CAL09/
    • THANK YOU