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

Design Pattern For C# Part 1

on

  • 5,981 views

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>

Statistics

Views

Total Views
5,981
Views on SlideShare
5,729
Embed Views
252

Actions

Likes
1
Downloads
367
Comments
0

3 Embeds 252

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

Accessibility

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

Design Pattern For C# Part 1 Design Pattern For C# Part 1 Presentation Transcript

  • Design Patterns The core of Software architecture Creational Patterns- Part-1 By: Shahzad Sarwar
  • 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
  • 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)
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • Abstract Factory Design ( Creational Patterns )
    • Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
  • 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
  • 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.
  • 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
  • Prototype( Creational Patterns )
    • Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.
  • 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
  • Builder
    •     Separate the construction of a complex object from its representation so that the same construction process can create different representations.
  • 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
  • Criticism on Design Patterns
    • Targets the wrong problem
    • Lacks formal foundations
    • Leads to inefficient solutions
    • Does not differ significantly from other abstractions
  • Reference:
    • www.dofactory.com
    • www.oodesign.com
    • http://wiki.asp.net/page.aspx/276/design-patterns/
    • http://sourcemaking.com/design_patterns
  • Further Discussion
    • A soft copy will be available at:
    • http:// softarchitect.wordpress.com
    • For Future discussion, join
    • http:// tech.groups.yahoo.com/group/SoftArchitect /