Factory

Document Sample
Factory Powered By Docstoc
					Low Budget Productions, LLC
             Presents
   “The Factory Method Pattern”
 Co-Executive Producers
         Trisha Rogers
Gamma, Helm, Johnson and Vlissides
         Martin Fowler
           Wikipedia
    A host of internet writers


    Creative Consultant
         Mark Shacklette
Act I: Scene 1: Design for Change
  Open for extension but closed for
   modification
  Design system to evolve while maximizing
   code reuse and eliminating changes to
   existing classes and client classes
        Factory Method Pattern: Take the code that is likely to
         change over time and put it in its own class
    Create objects without specifying the exact
     class of the object that will be created
             Commit to the interface not the implementation
             Factory Method Pattern: defers instantiation to
              subclasses
Act I: Scene 2: Design pattern space

  Purpose: A creational pattern, concerned
   with the process of object creation
  Scope: Class scope
       Factory Method Pattern applies primarily to
        classes and their subclasses
       These relationships are established through
        inheritance and so are static - fixed at compile
        time. Factory Method Pattern deals with the
        dilemma of not knowing what the client will want
        until run-time.
Act I: Scene 3: Factory Method Purpose

     Problems:
          What if it is the nature of the application to have classes that change
           on a regular basis (new products, e.g.) and code re-writing will have
           to be done frequently?
          What if the classes are abstract and they do not know how the
           subclasses will be implemented?

     Solution:
           Factory Method Pattern can defer instantiation to subclasses,
           encapsulating the knowledge of which subclass to create and move
           this knowledge to a separate class.
          This pattern helps to model an interface for creating an object which
           at creation time can let its subclasses decide which class to
           instantiate. It is called a Factory Pattern since it is responsible for
           "Manufacturing" an Object. It helps instantiate the appropriate
           Subclass by creating the right Object from a group of related classes.
           The Factory Pattern promotes loose coupling by eliminating the need
           to bind application-specific classes into the code.
Act I: Scene 3: Factory Method Purpose

     Variation on the theme: Parameterized factory methods
         Problem: What if there is ambiguity in the meaning of the
          constructor parameters? Only one constructor is allowed per class,
          and while overloading will solve the problem of passing different
          types of parameters, it will not solve problem of the same type with
          different meanings.
         Solution: Create a factory class that will privatize the constructor
          and pull all the logic into one class. Provide different static methods
          to return the appropriate object depending on the meaning. Example
          to follow.
         Problem: You want a simple concrete creator class to handle object
          creation depending on a passed parameter?
         Solution: Create a factory class that will privatize the constructor
          and pull all the logic into one class. Write a switch statement to
          handle various parameters. If there is an addition of a sub-class, fix
          code in the factory class only. The interface does not change.
          Example to follow.
Act I: Scene 4: Where to use it
    Three basic situations
        Frameworks
             High level software written for an industry
             Abstract classes used to define and maintain relationships
              between objects
             A company in the industry will purchase the framework
              and implement the subclasses to its own specifications
             So if there aren’t many/any subclasses in the framework,
              how does the framework developer create objects?
             Encapsulates the knowledge of which subclass to create
              and moves this knowledge out of the framework
        Parallel hierarchies
             Application class cannot anticipate the subclass to be
              instantiated at run-time; it knows when, not what kind.
        “Little Factories” with logic in one place
Act I: Scene 5: UML per GoF
Act II: Scene 1: Old Approach
Act II: Scene 2: Factory Method
Act II: Scene 2: Factory Method
    Scenario:
        A bank has multiple types of accounts. These are
         subclasses of the class Account. There is a saving
         account class and a checking account class. The
         client uses a factory method class as an interface.
        When a new type of account is added – an IRA
         account – no changes need to be made to the
         abstract account class, the savings account class
         or the checking account class.
        More importantly, no changes need to be made to
         the client class.
        Only changes in the factory class need to be made
         to add the new product – IRA account.
        See the example in Eclipse.
Act II: Scene 3: Disambiguation Example

     How to use a factory method pattern to solve problem
      of multiple meanings for parameters:
         Make the constructor private
         Add one or more factory methods that are static and
          accessible from the public class. Example is from Wikipedia.

      class Complex {
      private Complex(double a, double b) { //... }

      public static Complex fromCartesian(double real, double imag) {
         return new Complex(real, imag);
      }
      public static Complex fromPolar(double modulus, double angle) {
           return new Complex(modulus * cos(angle), modulus * sin(angle));
       }
      }

      Complex c = Complex.fromPolar(1, pi); // Same as fromCartesian(-1, 0)
Act III: Scene 1: Limitations
     The first limitation is that refactoring an existing class to use factories
      breaks existing clients. For example, if class Complex was a standard
      class, it might have numerous clients with code like:
          Complex c = new Complex(-1, 0);
          Once we realize that two different factories are needed, we change the class
           (to the code shown earlier). But since the constructor is now private, the
           existing client code no longer compiles.
     The second limitation is that, since the pattern relies on using a private
      constructor, the class cannot be extended. Any subclass must invoke the
      inherited constructor, but this cannot be done if that constructor is
      private.
     The third limitation is that, if we do extend the class (e.g., by making the
      constructor protected -- this is risky but possible), the subclass must
      provide its own re-implementation of all factory methods with exactly the
      same signatures. For example, if class StrangeComplex extends
      Complex, then unless StrangeComplex provides its own version of all
      factory methods, the call StrangeComplex.fromPolar(1, pi) will yield an
      instance of Complex (the superclass) rather than the expected instance
      of the subclass.
Coda:



    Never, ever follow student presenter Will
     Rodgers (the state pattern with the Pepsi
     machine guy) in any presentations. Ever.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:36
posted:8/6/2011
language:English
pages:14