The static Keyword

Photo by Nacho A on Unsplash

The static keyword in object-oriented languages is not at all about object-orientation. And we need to be aware of the effects that come from marking methods and data as static. Incorrect and excessive use of static can cause spurious and hard to find bugs, and damage our software architecture. 

Today we’ll review the behaviour of static.

In object-oriented languages, like C#, programmers create objects to carry out business objectives. These objects are instances of particular types, say Customer, Order, Payment, and so on, to model the given business domain. 

So, an instance of a class is an object. Multiple objects of the same type can exist at the same time. Objects encapsulate and manage their state. 

However, in C# and other statically typed languages, there is a way of sharing data and methods—the static keyword. When we mark a property, method or class member as static, then there can be only one of these. In VB.NET the analog is the ‘Shared‘ keyword—this is a better description of what is going on. A shared/static method exists only once in the program’s memory. With shared or static data, only one copy of the data exists.

OK, let’s look at some code:

  public class Person
  {
     public static int Count { get; private set; }
     public string Name { get; }

     public Person(string name)
     {
        Name = name;
        Count++;
        Log();
     }

     public void Log()
     {
        Console.WriteLine($"Name: '{Name}'. Count: {Count}.");
     }
  }

Name is an instance property—each Person object will contain its own Name data. Count is a static property—its value is shared between all the Person objects. What does that mean?

This program listing produces the following output.

  class Program
  {
     static void Main(string[] args)
     {
        var fred = new Person("Fred");
        var barney = new Person("Barney");
        var wilma = new Person("Wilma");

        Console.WriteLine($"Person.Count: {Person.Count}.");

        fred.Log();
        barney.Log();
        wilma.Log();
     }
  }

Output:

  Name: 'Fred'. Count: 1.
  Name: 'Barney'. Count: 2.
  Name: 'Wilma'. Count: 3.
  Person.Count: 3.
  Name: 'Fred'. Count: 3.
  Name: 'Barney'. Count: 3.
  Name: 'Wilma'. Count: 3.

As each object is created, the Count property is incremented by one. Thereafter Count stays at 3 and the Log() method shows that even though the Name for each Person instance differs, Count remains at 3.

Since anything static is independent of any given object instance, we can access statics using only the class name. For example: 

  Console.WriteLine($"Person.Count: {Person.Count}.");

This line calls the static Count property directly on the Person type. In fact, outside of the Person class that is the only way in which we can access Count. 

This line will not compile:

var count = wilma.Count;   // won't build

Static property Count is not accessible through a Person object. 

That’s it for today.

In a future article, we’ll find out how static can cause problems in our programs.