I must admit that my first exposure to object oriented programming (OOP) was frustrating and difficult. As a hobbyist I have struggled through Z80 assembly and EPROM burners, BASIC, Turbo Pascal, Java, C++ COM and now C#. The move to event driven programming and then to object oriented programming presented major conceptual hurdles to my function driven sequential programming mindset. The “aha” moment when OOP made sense was most gratifying, but did not come quickly or easily. It has been a few years since I “got” the OOP mindset and I feel comfortable enough now to try to help fellow travelers with this journey. If OOP comes easily to you, feel free to skip this tutorial. If you are having problems getting your mind around objects and inheritance I hope this tutorial can help you. This tutorial does not represent a conventional teaching method. It assumes a passing knowledge of the C# language and familiarity with the Visual Studio .NET IDE. This is a work in progress and may require correction or revisions.
Comments are actively requested (email: Jeff_Louie@yahoo.com).
Useful Texts
I highly recommend the following books. Much of my understanding of OOP has been gleamed from these “classic” texts and then reinforced from coding database projects in Java, C++ and C#. At all times I willfully try to avoid plagiarizing these authors, but my understanding of OOP is so closely tied to these texts that I must cite them as sources of knowledge right from the start!
Object-Oriented Analysis and Design with Applications Grady Booch, Second Edition, Addison-Wesley, 1994, 589pp.
Design Patterns Elements of Reusable Object-Oriented Software Gamma Helm, Johnson and Vlissides, Addison-Wesley, 1994, 395pp.
Object-Oriented Software Construction Second Edition Bertrand Meyer, Prentice Hall, 1997, 1254pp.
Of course, some of this material is a descendent of my writing from our now out of print book:
Visual Café for Java Explorer Database Development Edition Brogden Louie and Tittle, Coriolis, 1998, 595pp.
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#.
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:
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;
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. 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.
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.
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 is quite complicated. 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";
}
}
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.
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 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();
}
}
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.
All Rights Reserved Jeff Louie 2002
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
More ASP.NET Articles
More By aspfree
 developerWorks - FREE Tools!
|
As businesses grow increasingly dependent upon Web applications to provide services to customers, employees and partners, these complex applications become more difficult to secure. Although traditional security solutions protect Internet infrastructure layers, they do not guard against HTTP and HTML attacks. Many organizations that conduct security testing still deploy applications that allow attackers to manipulate their logic and wreak havoc on their business. To mitigate this risk, development and delivery teams must address Web application security throughout the lifecycle, addressing the many layers detailed in this paper.
FREE! Go There Now!
|
|
|
|
Learn how you can extend modern application lifecycle management to IBM System z through the IBM Rational Software Delivery Platform (SDP). The Did you say mainframe? e-kit includes podcasts, webcasts, tutorials, white and red papers, demos, and articles designed to help ease the challenges of modernizing your enterprise. This complimentary kit for mainframe developers is a practical, how-to guide for making the most of an existing development environment, including the skills and infrastructure already in place at an established enterprise.
FREE! Go There Now!
|
|
|
|
Download a free trial version of IBM Rational Developer for System i V7.1, which provides a complete development environment for traditional i5/OS application development. IBM Rational Developer for System i is a new eclipse-based workstation offering for i5/OS application development that provides a comprehensive Integrated Development Environment for edit/compile/debug of traditional RPG/COBOL/C/C++ i5/OS applications.
FREE! Go There Now!
|
|
|
|
This Fall, IBM Rational talks to you directly through a special teleconference series giving you access to the best minds in IBM Rational - product experts and market thought leaders who will answer your questions during these pre-scheduled telephone conference calls. Register today!
FREE! Go There Now!
|
|
|
|
Join this Rational Talks to You teleconference on December 4 at 1:00 pm ET to discuss how Rational Method Composer can help meet your compliance objectives. Get your questions answered!
FREE! Go There Now!
|
|
|
|
This whitepaper provides areas to consider when evaluating any software configuration management solution. It addresses how the IBM solutions (Rational ClearCase and Rational ClearQuest) meet the needs and requirements of both project leaders and developers to provide successful Software Change and Configuration Management.
FREE! Go There Now!
|
|
|
|
This paper is about the critical role that a discipline called integrated requirements management can play in helping to ensure that your business goals and IT investments are continuously aligned—whether you are sourcing, integrating, building or maintaining software. It also looks at ways that automated IBM Rational® products can work together to help you use requirements in the very best way.
FREE! Go There Now!
|
|
|
|
Get a free trial download of IBM Lotus Forms V3.0 (formerly Workplace Forms), which provides a zero-footprint eForms solution to help you automate and move forms-based business processes off the desktop and onto the Web. With Lotus Forms, you can extend applications beyond the firewall by creating a single electronic form document ready for use in both thick and Web 2.0 thin client format.
FREE! Go There Now!
|
|
|
|
The discipline of assembling and delivering software is maturing beyond standard developer-centric compile/test software builds. The end-to-end software development lifecycle is emerging as the new focus moves “Beyond the Build.” Join this on demand webcast to learn about methods for streamlining software delivery and key capabilities of the IBM Rational Build Forge framework for automating build and release management in environments of any size.
FREE! Go There Now!
|
|
|
|
WebSphere Process Server delivers a unique integration framework that simplifies existing IT resources. Often, as IT assets grow to support business demand, so too does their complexity and manageability. In this webcast, we’ll discuss how WebSphere Process Server helps deliver an SOA infrastructure that provides a common model to orchestrate, mediate, connect, map, and execute the underlying IT functions. Discover how WebSphere Process Server simplifies integration of business processes by leveraging existing IT assets as reusable services without the complexities of traditional integration methodologies.
FREE! Go There Now!
|
|
|
|
All FREE IBM® developerWorks Tools!
|
