Abstract Factory Pattern

Provides an interface for creating families of related or dependent objects without specifying their concrete classes.



1. It relies on object composition, object creation is in methods exposed in the factory interface.

2. Example from .NET

a. DbProviderFactory is an abstract factory.
b. It is implemented by SqlClientFactory, OdbcFactory
c. SqlClientFactory returns SqlCommand, OdbcFactory returns OdbcCommand

 namespace System.Data.Common { 
  public abstract class DbProviderFactory { 
    protected DbProviderFactory(); 
    public virtual bool CanCreateDataSourceEnumerator { get; } 
    public virtual DbCommand CreateCommand(); 
    public virtual DbCommandBuilder CreateCommandBuilder(); 
    public virtual DbConnection CreateConnection(); 
    public virtual DbConnectionStringBuilder CreateConnectionStringBuilder(); 
    public virtual DbDataAdapter CreateDataAdapter(); 
    public virtual DbDataSourceEnumerator CreateDataSourceEnumerator(); 
    public virtual DbParameter CreateParameter(); 
    public virtual CodeAccessPermission CreatePermission(PermissionState state); 
  } 
} 

Factory Method Pattern

All factory patterns encapsulate object creation. The Factory Method Pattern encapsulates object creation by letting subclasses decide what objects to create.

Definition
The factory method pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory method lets a class defer instantiation to subclasses.

Simple

1. You have a base class with an abstract method.
2. The abstract method is a factory method which returns different products.
3. The child classes implements the factory method and returns different products.
4. The base classes uses the products without knowledge of how they were created.

Simple Factory

1. The simple Factory Method is not a design pattern but more of a programming idiom.

2.

a. The client of factory uses factory to create instances of concrete classes.
b. The create() method is often declared statically.



3. Example

 public interface IPizza 
{ 
  decimal Price { get; } 
} 
public class HamAndMushroomPizza : IPizza 
{ 
  decimal IPizza.Price 
  { 
    get 
    { 
      return 8.5m; 
    } 
  } 
} 
public class DeluxePizza : IPizza 
{ 
  decimal IPizza.Price 
  { 
    get 
    { 
      return 10.5m; 
    } 
  } 
} 
public class HawaiianPizza : IPizza 
{ 
  decimal IPizza.Price 
  { 
    get 
    { 
      return 11.5m; 
    } 
  } 
} 
public class PizzaFactory 
{ 
  public enum PizzaType 
  { 
    HamMushroom, 
    Deluxe, 
    Hawaiian 
  } 
  public static IPizza CreatePizza(PizzaType pizzaType) 
  { 
    IPizza ret = null; 
    switch (pizzaType) 
    { 
      case PizzaType.HamMushroom: 
        ret = new HamAndMushroomPizza(); 
        break; 
      case PizzaType.Deluxe: 
        ret = new DeluxePizza(); 
        break; 
      case PizzaType.Hawaiian: 
        ret = new HawaiianPizza(); 
        break; 
      default: 
        throw new ArgumentException("The pizza type " + pizzaType + " is not recognized."); 
    } 
    return ret; 
  } 
} 

Drawbacks

1. Number of implementation classes is hardwired into the factory method. Therefore, even though there is an interface for the implementation objects, it's impossible for the factory method to return an implementation class that it does not know about. This limits extensibility, especially in the case of a public API and application frameworks, where the ability to dynamically introduce new implementation classes is not only desired, but often expected to achieve a certain degree of flexibility.

2. Even if the ability to dynamically introduce new implementations existed, the client application would still need to know which class to ask for. This eliminates some of the flexibility that the factory class was supposed to provide.

Dependency Injection

Dependency Injection (DI), which allows you to inject objects into a class, rather than relying on the class to create the object itself.

When a component creates a private instance of another class, it internalizes the initialization logic within the component. This initialization logic is rarely reusable outside of the creating component, and therefore must be duplicated for any other class that requires an instance of the created class.

1. Factory

The use of a factory class is one common way to implement DI

1. It is not reusable across other applications.
2. Frequently all of the available creation options are hardcoded into the factory implementation, making the factory itself non-extensible.
3. Also, most of the time the class calling the factories' creation methods must know which subclass of the factory to create.
4. All dependencies for an object that is created using a factory are known to the factory at compile time. At run time there is no way to insert or alter the manner in which objects are created, or which dependencies are populated.
5. Since factories are custom to each individual implementation, there can be a significant level of cross-cutting infrastructure that is held captive inside a particular factory.
6. Factories rely on well-defined interfaces to achieve polymorphism. In order for a factory implementation to be able to dynamically create different concrete subclass instances, there must be a common base class or shared interface implemented by all classes that the factory will create. Interfaces decouple the construction of the object from the specific implementation of the interface. The dilemma that arises now is how you can accomplish this decoupling without being forced to create an interface for everything.

2. Containers

DI containers provide generic factory classes that instantiate instances of classes. These instances are then configured by the container, allowing construction logic to be reused on a broader level.

They provide

1. Not only factories for creating objects.
2. Also, dependency resolution.

For more details, please refer to MSDN article.

MSDN article

Separated Interface

Defines an interface in a separate package from its implementation.

1. You can put interfaces in the same package as that of the client.

2. Or put interfaces in a third package.

Now, how does the client instantiate the implementation as this would require knowledge of the implementation class. There are two approaches for this

1. Use a separate factory object, where again there is a separated interface for the factory. And to bind an implementation to the factory, Plugin can be used.

2. Let yet another package that knows both the interface and implementation and it instantiates the right objects at startup.

Model View Controller

Most of the applications get data from a data store and display it to the user. And if the user changes the data, the data store is updated.



UI <--> Data



Problem



If Data and UI are coupled,



1. UI changes more frequently than the data stored in the system.

2. Business logic gets in UI



Model is an object that represents some information about the domain. It's a nonvisual object containing all the data and behavior other than that used for the UI.



The view represents the display of the model in the UI. The view is only about display of information; any changes to the information are handled by the controller. The controller takes user input, manipulates the model, and causes the view to update appropriately. In this way UI is a combination of the view and the controller.



There occurs two separations



1. Presentation from model



Besides other advantages, it allows for easy testing of domain logic.



Principle : The presentation depends on the model but the model doesn't depend on the presentation.



This principle introduces a common issue. With a rich-client interface of multiple windows it's likely that there will be several presentations of a model on a screen at once. If a user makes a change to the model from one presentation, the others need to change as well. To do this without creating a dependency you usually need an implementation of the Observer pattern. The presentation acts as the observer of the model.



2. View from controller



Separation required to support editable and noneditable behavior, which you can do with one view and two controllers for the two cases, where the controllers are strategies for the view. In practice most systems have only one controller per view, however, so this separation is usually not done.

API Design Guidelines - Progressive APIs

What are progressive APIs ?

1. Low barrier to entry (and get progressively difficult)
2. Powerful
3. Consistent

API Design Principles

1. Scenario-Driven Design
a. Define top scenarios.
b. Write code samples, design API later.
c. Make top scenarios easy, make the rest possible.
d. Usability test top scenarios. (Preferably other language)

2. Support Experimentation
a. Obvious entry points
A good way to indicate entry point is to use domain correspondence.
b. Minimal initialization, sensible defaults
c. Usage of properties
d. Immediate feedback (exception)

3. Aggregate Component
a. Create, set and call usage pattern
b. They build on the factored types

4. Self-Documenting APIs
a. Consistency
If you learn one part, you can know the other part
b. Progressive documentation
It has to start with simple scenario and then go to advanced concepts.


5. Keep things simple
a. Number of objects - less objects should be required to setup.
b. OO design methodologies is not meant for API design.