Alex Mueller on Software and Technology 
Sunday, May 07, 2006

When using static classes and members, consider some of the following when designing a solution. One is an understanding of the differences between a class method and an instance method. A second is an understanding of the design of the system being developed, its domain, as well as the nature of its need to change in the future. Thread safety is another consideration. The following journal entry will provide information about using static classes and members under these conditions.

Instance and Class Methods
Instance methods rely on the state of the object instance. These methods are tied to a given object instance because the behavior that these methods access is dependent upon the state of that object. Instance methods can modify the state of the object. Every instance of the object has its own state, and that state can vary independently from all other instances of that object.

Class methods, or static methods, apply to the class and not to any one given instance of the object. The class method does not rely on the state of a specific object. This is enforced since a static method cannot access an instance's state. This is the reason why the "this" keyword, which refers to an instance of a class, cannot be used in a static method. It is possible, however, to pass an object instance to a static method, but this practice breaks the rules of encapsulation, and that is poor design. Static methods cannot access instance variables, only other static variables.

Static Classes and Methods

Static classes are sealed or final, and so they cannot be inherited. A static class should be denoted as sealed to provide increased readability. If a class is designed with static methods, these methods cannot be overridden. A derived class can inherit a static member in C#, but that member cannot be labeled as override, virtual, nor abstract. If classes need to be extended, they should not be declared static.

Static methods cannot be used with remoting in a distributed system. The static methods and fields are accessed using a remoting proxy, and are executed locally on the client. These methods never leave their application domain because they do not declare a method of serialization.

Thread Safety

Thread safety becomes an issue when static methods modify static state. Since static state is shared across all object requests, multiple threads can conflict when accessing data. Not all uses of static functions threaten thread safety, but it is something to consider. Be aware of the performance issues when using locks as a means to implementing thread safety.

Typical Static Usage

Static methods are typically used when the behavior does not modify or require state information within a class. Static methods usually take all their data passed in as parameters, do some computation, and return an object. Generally, the nature of these functions lends itself to utility classes, function libraries, and factory methods. Static properties are useful for storing configuration data, read-only data, and one-time references for application wide settings.

The factory pattern relies on static factory methods. Some benefits of static factory methods are that they can have more intuitive names other than their class name. Static factory methods can improve performance since they do not have to instantiate new objects each time, and by allowing object instantiations to be cached in situations where object creation is expensive or frequently used. Static factory methods can return subtypes of their return type, such as an interface. This is useful when designing systems that program to interfaces and not implementations. Static methods can return objects of private classes.

Knowing when to use the static keyword requires knowledge of the system for which one designs, the differences between class and instance methods, and thread safety. Familiarization with the nature of static classes and members will improve system performance and reduce unwanted behavior. As with any design, it is impossible to foresee all requirement changes down the pike, but with proper techniques, we can better position ourselves to respond to change.

Sunday, May 07, 2006 12:39:10 PM (Mountain Standard Time, UTC-07:00) | Comments [0] | Design#
Comments are closed.
MuellerDesigns.net
Search
On This Page
PowerShell Documentation
Automate Daily Tasks with PowerShell
SketchPath XPath Editor
Software Testing - Revisited
Architecting Buildings and Software
NBCOlympics.com with Silverlight
Marker Interfaces and C# Attributes
The Phone Screen
Working with ASP.NET MVC and MvcContrib
Thanks to BDD
Twitter
The Opposite of a Singleton?
Removing Duplicate Code in Functions
Add Vista Themes to Longhorn
Changing File Ownership In Vista and Longhorn
Most Popular
JavaScript ReplaceAll Functionality
What is polymorphism?
What is composition?
Sorting with IComparable and IComparer
Applying the Observer Pattern in ASP.NET
MVP in ASP.NET
What is abstraction?
What is encapsulation?
What is a class?
What is inheritance?
Authentication in ASP.NET
Calendar Controls
XPathNavigator.CheckValidity new for 2.0
SQL Server 2005 Connection Issues
Auto-attach to process '[####] aspnet_wp.exe' on m...
What is an object?
FreeTextBox
VMWare and VPC
An Example of Reflection using C#
Caring for the Team
Archive
Links
Categories
My Local Blog Map
Blogroll
About
Powered by:

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2009
MuellerDesigns.net

Sign In

Help Those In Need
The Hunger Site
Ronald McDonald House Charities (RMHC) of Western Washington & Alaska