Design Pattern For C# Part 1
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Design Pattern For C# Part 1

  • 6,296 views
Uploaded on

This is series of presentations covering Design patterns ...

This is series of presentations covering Design patterns

<strong>Creational Patterns Part -1</strong> Abstract Factory , Builder , Factory Method , Prototype , Singleton
<strong>Structural Patterns Part-2 ( Later ) </strong> Adapter , Bridge , Composite , Decorator , Facade , Flyweight , Proxy
<strong>Behavioral Patterns Part-3 ( Later )</strong>
Chain of Resp , Command , Interpreter , Iterator
,Mediator , Memento , Observer , State , Strategy ,
Template Method , Visitor

<strong>AJAX Design Patterns Part-4 (Later)</strong>
AJAX Level I , AJAX Level II
AJAX Message Patterns
(Text Message , HTML Message , XML Message , XSL Message , JavaScript Msg , JSON Message , Custom Message )

<strong>Software AntiPatterns Part-5 (Later)</strong>

<strong>Software Refactoring Part-6 (Later)</strong>

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

Views

Total Views
6,296
On Slideshare
6,044
From Embeds
252
Number of Embeds
3

Actions

Shares
Downloads
377
Comments
0
Likes
1

Embeds 252

http://softarchitect.wordpress.com 245
http://www.slideshare.net 6
http://www.slashdocs.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Design Patterns The core of Software architecture Creational Patterns- Part-1 By: Shahzad Sarwar
  • 2. Agenda - Future Architecture Tracks
    • This is series of presentations covering Design patterns
    • Creational Patterns Part -1
    • Abstract Factory  ,  Builder   ,  Factory Method   ,  Prototype   ,  Singleton
    • Structural Patterns Part-2 ( Later ) Adapter  ,   Bridge  ,  Composite  ,  Decorator  ,  Facade  ,  Flyweight   ,  Proxy
    • Behavioral Patterns Part-3 ( Later )
    • Chain of Resp   ,  Command   ,  Interpreter  ,  Iterator  
    •   , Mediator  ,  Memento  ,  Observer  ,  State  ,  Strategy  , 
    • Template Method  ,  Visitor
  • 3. Agenda - Future Architecture Tracks
    • AJAX Design Patterns Part-4 (Later)
    • AJAX Level I  ,  AJAX Level II
      • AJAX Message Patterns
      • ( Text Message  ,   HTML Message  ,  XML Message  ,   XSL Message   ,  JavaScript Msg  ,   JSON Message  ,  Custom Message   )
    • Software AntiPatterns Part-5 (Later)
    • Software Refactoring Part-6 (Later)
  • 4. Design Pattern
    • In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
    • Types of Design Patterns:
    • Creational design patterns
    • Structural design patterns
    • Behavioral design patterns
  • 5. Design Principles
    • Robert Martin &quot;Agile Software Development: Principles, Patterns, and Practices“
    • Characteristics of a bad design:
      • Rigidity - It is hard to change because every change affects too many other parts of the system.
      • Fragility - When you make a change, unexpected parts of the system break.
      • Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.
  • 6. Software Design Principles
    • Open Close Principle
      • Software entities like classes, modules and functions should be open for extension but closed for modifications.
    • Dependency Inversion Principle
      • High-level modules should not depend on low-level modules. Both should depend on abstractions.
      • Abstractions should not depend on details. Details should depend on abstractions.
  • 7. Software Design Principles
    • Interface Segregation Principle
      • A class should have only one reason to change.
      • Tom DeMarco, His book Structured Analysis and Systems Specification, 1979.
      • Robert Martin reinterpreted the concept and defined the responsibility as a reason to change.
  • 8. Singleton( Creational Patterns )
    • Ensure a class has only one instance and provide a global point of access to it.
    • Participants
    • Examples
    • 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.
  • 9. Abstract Factory Design ( Creational Patterns )
    • Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
  • 10. Participants
    • The classes and/or objects participating in this pattern are:
    • 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
    • Examples
  • 11. Factory Method( Creational Patterns )
    • Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
  • 12. Participants
    • The classes and/or objects participating in this pattern are:
    • 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.
    • Examples
  • 13. Prototype( Creational Patterns )
    • Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
  • 14. Participants
    •      The classes and/or objects participating in this pattern are:
    • Prototype    (ColorPrototype)
      • declares an interface for cloning itself
    • ConcretePrototype    (Color)
      • implements an operation for cloning itself
    • Client    (ColorManager)
      • creates a new object by asking a prototype to clone itself
    • Examples
  • 15. Builder
    •     Separate the construction of a complex object from its representation so that the same construction process can create different representations.
  • 16. Participants
    • The classes and/or objects participating in this pattern are:
    • Builder    (VehicleBuilder)
      • specifies an abstract interface for creating parts of a Product object
    • ConcreteBuilder    (MotorCycleBuilder, CarBuilder, ScooterBuilder)
      • constructs and assembles parts of the product by implementing the Builder interface
      • defines and keeps track of the representation it creates
      • provides an interface for retrieving the product
    • Director    (Shop)
      • constructs an object using the Builder interface
    • Product    (Vehicle)
      • represents the complex object under construction. ConcreteBuilder builds the product's internal representation and defines the process by which it's assembled
      • includes classes that define the constituent parts, including interfaces for assembling the parts into the final result
    • Examples
  • 17. Criticism on Design Patterns
    • Targets the wrong problem
    • Lacks formal foundations
    • Leads to inefficient solutions
    • Does not differ significantly from other abstractions
  • 18. Reference:
    • www.dofactory.com
    • www.oodesign.com
    • http://wiki.asp.net/page.aspx/276/design-patterns/
    • http://sourcemaking.com/design_patterns
  • 19. Further Discussion
    • A soft copy will be available at:
    • http:// softarchitect.wordpress.com
    • For Future discussion, join
    • http:// tech.groups.yahoo.com/group/SoftArchitect /