Creating a Class Factory with C# and .NET

Introduction

Developing dynamic, flexible, and maintainable applications these days is a

necessary, yet difficult task. Systems grow at exponential rates as companies

require more and more advanced logic to run their businesses. The ability of a

programmer to understand and maintain such systems diminishes as a systems

complexity increases. The creative programmer can come up with ways to combat

the difficulties in maintaining a complex system, but often those ways are

ignored when new functionality must be developed in a very short time (which, as

already known code. Since a deadline prevents that code from being developed

initially, it must be added later on. Since the required functionality is

already known, its fairly easy to plan for it and make the system ready for it.

Prior knowledge of what future functionality a system may require is not always

possible, though.

In the situations where you know the system will need to be extended, but what

extensions will be necessary are not known, the ability to plan for those

extensions is greatly reduced. You can't build in fixed placeholders or hooks

for the future functionality. If you do build in hooks, they must be generic,

capable of loading code without prior knowledge of its inner workings. This

has fallen in the face of n-tier systems, object oriented programming,

inheritance and polymorphism, modular development, and design patterns. Greater

strides in project management have been made to make better use of these better

ways of thinking about development. This article focuses on the aspect of Design

Patterns, and in particular, a specific pattern called a Class Factory.

Design Patterns aren't as tangible a thing as a class or method. A design

pattern is more a way of thinking, about the code you intend to write and how

that code will be used in a system. Design patterns help fuel creative thinking

when planning all or part of a larger system, and can help save time by

providing something of a template to begin working from. There are many design

the topic of this article, allows the creation and use of classes without

knowing all the details of those classes, and without needing to directly

instantiated those classes.

The Abstract Factory: Some History

This article will focus on the creation of a Class Factory, which is similar in

concept to the Abstract Factory. The definition of an abstract factory is as

follows:

"Provide an interface for creating families of related or dependent objects

without specifying their concrete classes."

The development of an abstract factory requires a fair amount of forethought and

The theory behind the Abstract Factory is simply "implicit use", as opposed to

explicit use. A class that is marked as abstract is non-instantiable, an

implicit representation of all the classes that derive from it. When one of

those derived classes is instantiated with new, the class is being "explicitly

used". With an abstract factory, the client can implicitly use any classes

derived from the abstract products that are producible with the abstract

factory. The client does not have explicit knowledge of either ProductA1 or

ProductB1, and any additional functionality in those classes not defined in

AbstractProductA or AbstractProductB will not be available to the client.

MethodA and MethodB can be called, but MethodX and MethodY are unknown to the

public abstract AbstractProductA CreateProductA();

public abstract AbstractProductB CreateProductB();

}

// Contrete Factory #1

public class ConcreteFactory1: AbstractFactory

{

public override AbstractProductA CreateProductA()

{

return new ProductA1();

}

public class ConcreteFactory2: AbstractFactory

{

public override AbstractProductA CreateProductA()

{

return new ProductA2();

}

public override AbstractProductB CreateProductB()

{

return new ProductB2();

}

// Abstract product B

public abstract class AbstractProductB

{

public abstract void MethodB();

}

// Product A1

public class ProductA1: AbstractProductA

{

public override void MethodA()

{

public override void MethodA()

{

Console.WriteLine("ProductA2.MethodA() Called");

}

}

// Product B1

public class ProductB1: AbstractProductB

{

public override void MethodB()

{

public override void MethodB()

{

Console.WriteLine("ProductB2.MethodB() Called");

}

}

// Client class, consumer of products and

// user of Abstract Factory

public class Client

{

public static void Main()

prodA = factory.CreateProductA();

prodB = factory.CreateProductB();

prodA.MethodA();

prodB.MethodB();

// Create instances of products from factory B

factory = new ConcreteFactoryB();

prodA = factory.CreateProductA();

prodB = factory.CreateProductB();

prodA.MethodA();

prodB.MethodB();

language, and its rigidity is a natural byproduct of that portability. In this

article, I'll introduce the Class Factory, a design pattern based on the

Abstract Factory, but tuned more to the .NET way of design and thinking. (NOTE:

If any other patterns exist with the name "Class Factory" they are likely

different than this pattern. This pattern is derived from a task I have had to

go several times, and appropriately, I developed a pattern for that task.) The

Class Factory will use many core .NET features such as reflection, interfaces,

dynamic class creation, etc.

The goals of the Class Factory pattern are similar but also different than those

of the Abstract Factory pattern. While the Abstract Factory aims to provide a

and possibly an advantage, of the Class Factory is it requires no prior

knowledge of the product classes whatsoever, relying on keys to instantiated