JAL Computing

Chapter 4 "Static Methods, Factories & Constructors"

Well, I've tried as long as possible to avoid the the "nuts and bolts" of object oriented programming. It's sort of like going in to the dentist for a root canal. You know it needs to be done, but it is going to be painful and you want to put it off. The good news is that once you have the root canal the pain goes away! So just dive in. In this chapter you will learn about static methods, factory methods and constructors. You will be introduced to the creational patterns "Class Factory" and "Singleton".

What Is a Static Field or Method?

Let's change the question. When is a field or method not part of an object? Answer: when it is part of the class! Remember, an object is an instance of a class and each object exists in a separate space in memory. It is possible to access class fields and class methods without creating an instance of a class using the "static" key word. Declaring a field or method with the static key word, tells the compiler that the field or method is associated with the class itself, not with instances of the class. In a sense, static or "class" fields and methods are global variables and methods that you can touch using the class name. If you think of a class as a blueprint used to create objects, then you can think of static fields and methods are being part of the blueprint itself. There is only one copy of the static fields and methods in memory, shared by all instances of the class.

Static fields are useful when you want to store state related to all instances of a class. A counter is a good example of a static field. The classic use of a static counter is to generate a unique ID or serial number for each instance of a class.

Static methods are useful when you have behavior that is global to the class and not specific to an instance of a class. In contrast, instance methods are useful when the method needs to know about the state of an object. Since data and behavior are intertwined in an object, instance methods have access to the instance fields and can exhibit behavior that is specific to the state of an object.

A Static Counter

Here is the classic example of a static counter that is zero based. It contains a static field "uniqueID" and a thread safe static method "GetUniqueID" that increments the unique ID:

/// <summary>
/// Summary description for TestStatic.
/// </summary>
class TestStatic
{
    // static stuff
    private static int uniqueID= 0;
    private static int GetUniqueID()
    {
        lock(typeof(TestStatic))
        {
            return uniqueID++; // returns zero at start
        }
    }

    // member stuff
    private int identity;
    public TestStatic()
    {
        this.identity= TestStatic.GetUniqueID();
    }
    public int Identity
    {
        get
        {
            return identity;
        }
    }
}

public class Test
{
     /// <summary>
    /// The main entry point for the application.
    /// </summary>
     [STAThread]
    static void Main(string[] args)
    {
        //
        // TODO: Add code to start application here
        //
        TestStatic ts1= new TestStatic();
        TestStatic ts2= new TestStatic();
        Console.WriteLine(ts1.Identity.ToString());
        Console.WriteLine(ts2.Identity.ToString());
        Console.ReadLine();
    }
}

If you compile and run this code the output is: 0 and 1. The static field "uniqueID" is global to the application and stores the value of the next unique ID. Each call to the constructor returns the unique ID and then increments the counter using the "postfix" operator ++. Notice how you use the class name to touch a static field or method:

ClassName.fieldName;
ClassName.MethodName();

Note: In Java you can touch a static field or method using the class name or a reference variable to an instance of a class. Not so in C#.

Here is a graphical view of the TestStatic class.

What's this?

Managing Concurrency Conflicts

The curious coder will note the call to "lock" which causes callers of the static method "GetUniqueID" to queue up to this method. (Lock is basically a shortcut to "Monitor.Enter" and "Monitor.Exit".) Locking inside the method insures that the method is thread safe. The problem is that the increment operator (++) is not an atomic operation, but performs a read and then a write. If you don't force callers to queue up to the increment operation it is possible for two callers to "almost simultaneously" enter the method. Both callers could read the uniqueID value before either caller can write the incremented value. In this case, both callers will receive the same ID. Not very unique! Be careful. If your locking code is poorly written, it is possible for two callers to queue up in a "catch-22" conflict where neither call can proceed, an example of "deadlock." The topic of locking, deadlock, and concurrency is an advanced topic not covered by this tutorial.

Let's Get Constructed

When you create an instance of an object using the key word "new", you call a class constructor. In fact, if you don't explicitly declare a class constructors, the compiler creates a hidden no argument constructor for you. Here is an example of explicitly declaring a no-arg do nothing constructor:

class Toaster
{
public Toaster() {} // this is a do nothing constructor
}

The compiler will create this constructor, if and only if, you do not declare any constructors for the class. The syntax for a public constructor is:

public NameOfClass(parameterList)
{
... stuff here
}

Let's Get Initialized

Constructors are often used to initialize the state of an object. Alternatively, you can initialize the instance fields when they are declared. Finally, you can break out the initialization code into a separate "Init" method. The following code demonstrates all three idioms for initializing an object:

/// <summary>
/// Summary description for Idioms
./// </summary>

class Idioms
{
    private Hashtable idiom1= new Hashtable();
    private Hashtable idiom2;
    private Hashtable idiom3;

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main(string[] args)
    {
        //
        // TODO: Add code to start application here
        //
        Idioms c= new Idioms();}

    public Idioms()
    {
        Init();
        idiom2= new Hashtable();
    }

    private void Init()
    {
        idiom3= new Hashtable();
    }
}

Assigning an instance variable a value when you declare the variable is an example of defensive programming. It minimizes the chance of forgetting to initialize a variable in the constructor or Init method.

Creating Multiple Constructors

A common programming task is to create multiple constructors that differ only in their parameter list. The C# language supports this concept by allowing you to "overload" a method name. As long as the parameter list is sufficiently unique, you can create multiple methods or constructors with the same name.

Note: Be careful not to confuse overloading with overriding. Overriding a virtual method is quite different than overloading a method or constructor. Overriding is a subject of a future tutorial. I promise.

It's time to resurrect the Toaster class. Here is a new version of the Toaster class with two new instance fields that contain information about the color of the toaster and the model name of the toaster:

class Toaster
{
    public const string DEFAULT_NAME= "Generic";
    public enum ColorType {Black, Red, Yellow, White};
    private static ColorType DEFAULT_COLOR= ColorType.Black;

    private ColorType color= DEFAULT_COLOR;
    private string modelName= DEFAULT_NAME;
}

Note the use of an enum "ColorType" to limit the domain of valid toaster colors. Here again is the default no-args constructor:

public Toaster(){} // black toaster with default name

The no-arg constructor simply leaves the default field values unaltered. You can now create a constructor that takes two parameters, the color type and the model name. Note that the constructor does validity checking to insure that the state of the object remains valid.

public Toaster(ColorType color, string modelName)
{
    this.color= color;
    if (modelName != null)
    {
        this.modelName= modelName;
    }
}

You can now create a constructor that only takes one parameter, the model name:

public Toaster(string modelName)
{
    if (modelName != null)
    {
        this.modelName= modelName
    }
}

Now this looks like redundant code, just begging to be refactored. Happily, C# allows you to chain constructor calls, eliminating the redundant null checking code. You can chain the two constructors like this:

public Toaster(string modelName) : this(DEFAULT_COLOR, modelName) {}

The syntax is:

public ClassName(someParameters) : this(someParameters) {}

Pretty cool! By using C#'s built in support for constructor overloading and constructor chaining you can write a series of constructors. Here is the final version of the Toaster class using multiple overloaded constructors:

    public Toaster(){} // black toaster with default name
    public Toaster(ColorType color, string modelName)
    {
        this.color= color;
        if (modelName != null)
        {
            this.modelName= modelName;
        }
    }
    public Toaster(ColorType color) : this(color,DEFAULT_NAME){}
    public Toaster(string modelName) : this(DEFAULT_COLOR,modelName) {}
    public string Color
    {
        get
        {
            return Enum.Format(typeof(ColorType), color,"G");
        }
    }
    public string ModelName
    {
        get
        {
            return modelName; // danger, return ModelName --> stack overflow!
        }
    }
}

What Is a Destructor?

C++ programmers are familiar with the concept of a destructor. I only briefly mention this topic here in self defense. In C++, a destructor is a method that is called when an object goes out of scope, is deleted, or the application closes. In C++, a destructor is often used to release valuable system resources. This works in C++ since memory reuse in C++ is deterministic. When an object in C++ goes out of scope, the destructor is called and resources can be released immediately.

Things are quite different in C#. First, memory reuse in C# is based on garbage collection. In a nutshell, when application memory becomes limited, the garbage collector executes and attempts to reclaim memory by reclaiming objects that are not "reachable". As a result, in C#, you cannot depend on a destructor to reclaim system resources in a timely manner.

Second, although C# supports the syntax of destructors, destructors in C# simply map to finalize. According to the IDE documentation:

~ MyClass()
{
// Cleanup statements.
}

... is converted by the compiler to:

protected override void Finalize()
{
   try
   {
      // Cleanup statements.
   }
   finally
   {
      base.Finalize();
   }
}

If your object uses valuable external resources, you may want your class to inherit from the IDisposable interface and implement the Dispose method, calling GC.SuppressFinalize. You can then wrap your code with the using key word. When the object exits the "using" scope, the Dispose method will be called automatically! Alternatively, you want to rely on C#'s support for try, catch, finally to release external resources. For instance, you might want to open a connection in try and close any open connections in finally.

Note: Visual Studio C++ 2005 provides built in support for IDisposable with the concept of class instances that appear to be stack based. When a stack based object goes out of scope, Dispose is invoked.

The concept of garbage collection and reclaiming external resources is definitely beyond the scope of this tutorial.

Using Static Factory Methods Instead of Multiple Constructors

You might wonder why I have chosen to combine the topics of static methods and constructors into a single chapter. The answer is "static factory methods." Instead of writing multiple public constructors, you can write multiple static factory methods and private constructors that return objects. First, here is an example of a static factory method. The method simply constructs an object with default values and then returns a reference to the object. Unlike constructors, you can return null in a static factory method if you are unable to construct a valid object at runtime!

public static Toaster GetInstance()
{
return new Toaster(ColorType.Black, DEFAULT_NAME);
}

In a sense, this static method is analogous to the no-arg constructor.

public Toaster() {}

Here is the version of the Toaster class that uses static methods and a single private constructor to return toaster objects:

/// <summary>
/// Summary description for Toaster
/// </summary>
class Toaster
{
    // static factory methods
    public static Toaster GetInstance()
    {
        return new Toaster(ColorType.Black, DEFAULT_NAME);
    }
    public static Toaster GetInstance(string modelName)
    {
        return new Toaster(ColorType.Black, modelName);
    }
    public static Toaster GetInstance(ColorType color)
    {
        return new Toaster(color, DEFAULT_NAME);
    }
    public static Toaster GetInstance(ColorType color, string modelName)
    {
        return new Toaster(color, modelName);
    }

    public const string DEFAULT_NAME= "Generic";
    public enum ColorType {Black, Red, Yellow, White}; // black is the enum default value!
    private static ColorType DEFAULT_COLOR= ColorType.Black;

    private ColorType color= DEFAULT_COLOR;
    private string modelName= DEFAULT_NAME;

    // the single private constructor
    private Toaster(ColorType color, string modelName)
    {
        this.color= color; // ColorType cannot be null --> compile time error or defaults to ColorType.Black!
        if (modelName != null)
        {
            this.modelName= modelName;
        }
    }

    // the getters
    public string Color
    {
        get
        {
            return Enum.Format(typeof(ColorType), color,"G");
        }
    }
    public string ModelName
    {
        get
        {
            return modelName; // danger, return ModelName --> stack overflow!
        }
    }
}

Declaring the only constructor private, prevents any outside caller from directly instantiating the class. The only path to a Toaster object is through a static factory method. So, you can use multiple overloaded public constructors or multiple static factory methods and private constructors to create toaster objects. If you are interested in learning more about using static factory methods instead of multiple constructers check out Effective Java Programming Language Guide by Joshua Bloch, Addison-Wessley, 2001, 252 pp.

Note: The behavior of enum, a value type, is different from a reference type. You cannot set an enum to null and if you fail to explicitly initialize an enum variable, it defaults to the first member of the enumeration. For example:

public static ColorType c; // c --> ColorType.Black

Creational Patterns -- Class Factory and Singleton

I am going to finish off this chapter by introducing two common design patterns: the "Class Factory" and "Singleton" patterns. The class factory is useful when you want to return concrete objects that share a base class, at runtime. The singleton pattern is useful when you only want to allow the creation of one instance of an object in a application. These patterns are both considered "Creational" patterns since they abstract the creation of objects.

Using a Static Method to Return Concrete Classes -- The Class Factory.

The concept of using static methods to return objects is a useful one. In the previous code, you learned how to replace multiple constructors with multiple static factory methods. Another useful design pattern is the "Class Factory." A class factory can be used to return concrete implementations of a common base type.

In Chapter 2, you learned about polymorphism using the Drawable abstract class. Concrete implementations of the Drawable class such as square or circle provide a concrete implementation of the abstract "DrawYourself" method. Let's resurrect our Drawable class.

abstract class Drawable
{
    public abstract String DrawYourself();
}
class Circle : Drawable
{
    public override String DrawYourself()
    {
        return "Circle";
    }
}
class Square : Drawable
{
    public override String DrawYourself()
    {
        return "Square";
    }
}

Here is a graphical view of the Drawable classes.

In this example of the class factory pattern, you pass a parameter to a static factory method that then returns the appropriate concrete implementation of the Drawable abstract class. To insure that the method is passed valid parameters at compile time, you can define a type safe enum "DrawableType":

public enum DrawableType {CIRCLE,SQUARE};

Here is our class factory:

/// <summary>
/// Summary description for class Factory.
/// </summary>
class Factory
{
    public enum DrawableType {CIRCLE,SQUARE};
    public static Drawable GetInstance(DrawableEnum e)
    {
        if (e == DrawableType.CIRCLE)
        {
            return new Circle();
        }
        else if (e == DrawableType.SQUARE)
        {
            return new Square();
        }
        else
        {
            throw new IndexOutOfRangeException(); // should never get here
        }
    }

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main(string[] args)
    {
        //
        // TODO: Add code to start application here
        //
        Drawable d1= Factory.GetInstance(Factory.DrawableType.CIRCLE);
        Console.WriteLine(d1.DrawYourself());
        Drawable d2= Factory.GetInstance(Factory.DrawableType.SQUARE);
        Console.WriteLine(d2.DrawYourself());Console.ReadLine();
    }
}

Note that d1 and d1 are reference variables of the Type Drawable, yet the code outputs: Circle, Square. Polymorphism at work! The class factory design pattern allows your application to create concrete implementations of a base class or interface dynamically at runtime in response to user or system input.

Here is a graphical view of the Factory class.

Note: This example of a class factory is not very extensible. Later in this tutorial, you will learn about two approaches to "growable" class factories: type based and interface based class factories.

The Singleton Pattern

The "Singleton" pattern is a special version of the class factory that only returns a single instance of a class. The singleton pattern is useful when there should only be one instance of an object. As an example, there may be many soldiers that derive from person, but there should only be one reigning King of England that derives from person! Here is a sample that uses a static factory method to insure that only one instance is created. The factory method "GetInstance" returns a reference to the single instance of the class. Note that you must declare any constructors private, so that the constructors are not visible outside of the class. This insures that. there will be one and only one instance of MyClass.\

/// <summary>
/// Summary description for MyClass.
/// </summary>
class MyClass
{
    private static readonly MyClass theOnlyOne= new MyClass(); // create one and only one instance of the class
    public static MyClass GetInstance()
    {
        return theOnlyOne;
    }
    public readonly string description= "The One and Only.";
    private MyClass(){}

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main(string[] args)
    {
        //
        // TODO: Add code to start application here
        //
        MyClass mc= MyClass.GetInstance();
        Console.WriteLine(mc.description);
        Console.ReadLine();
    }
}

The Singleton Pattern adds a level of indirection. It allows encapsulation of methods and fields in a single namespace, the singleton class. It also allows modification of the factory method to support more than one instance of the class without breaking client code. The Singleton Pattern also supports sub classing / interfaces and allows you to limit access to the single instance. If you do not need this level of indirection, you can just use static methods and static fields.

using System;
using System.Collections.Generic;
using System.Text;

namespace TestSingleton
{
    interface MyInterface
    {
        void SayHello();
    } 
    class MySubClass : MyInterface {
        private static readonly MyInterface singleton = new MySubClass();
        public static MyInterface GetInstance()
        {
            return singleton;
        }

        private MySubClass() { ;}
        public void SayHello()
        {
            Console.WriteLine("Hello");
        }

        static void Main(string[] args)
        {
            MyInterface mi = MySubClass.GetInstance();
            mi.SayHello();
            Console.ReadLine();
        }
    }
}

One of the advantages of the factory method is that you can modify the singleton behavior of the class without affecting the caller of the class. If you decide that your application should now support Kings present and past, then you can modify MyClass to return a new instance for each call to GetInstance. Here is the modified multi-instance version of MyClass:

/// <summary>
/// Summary description for MyClass
/// </summary>
class MyClass
{
    public static MyClass GetInstance()
    {
        return new MyClass();
    }
    public readonly string description= "OneOfMany";

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    static void Main(string[] args)
    {
        //
        // TODO: Add code to start application here
        //
        MyClass mc= MyClass.GetInstance();
        Console.WriteLine(mc.description);
        Console.ReadLine();
    }
}

That's enough pain! I suggest the you jog around the block, clear your head and re-read this chapter later. In the next chapter, you will learn the top ten "gumption traps" for C++ and Java programmers.

Hosted by www.Geocities.ws