My brother, who is a DevOps and integrations whizz, got around to quizzing me, after hearing chatter amongst the nearby developer folk in his building, about the wonderful world of classes and instances, as they pertain to C#.
I reeled off the best explanation I could as I sipped on the best damn gin ever (actually, voted the UK’s best, check this out) and scoffed down some superb steak and chips. I didn’t think my musings were all that bad, but I got to thinking that formalising and solidify my thoughts on the matter wouldn’t hurt. Last aside, if you’re in Norfolk and fancy a good meal this is worth hitting up:
What is a steak…I mean, class!?
Food on the brain! Ok, in layman’s terms, a class simply defines a template or blueprint for anything being represented in a given computer program. This blueprint contains (but doesn’t have to and is not limited to), on a basic level, properties that describe the thing being templated and methods that represent actions or functions (that may or may not receive external stimuli, or variables) the, for want of a better term, thing can perform. The class, in and of itself, does nothing up until the point it is brought into life…meaning when an instance is created (ignoring static classes, for the purposes of this explanation).
So, what is an instance?
Instances, typically, are brought to life for actual use, in C#, using the new keyword and all we are doing here is bringing an occurrence (to try and avoid typing instance, again) of a given blueprint into being so the descriptive values of the object can be accessed and the functionality triggered.
I would normally use the tried and tested example of vehicles to show how this actually works, with a little dip into inheritance to boot, but I’m going off piste with the first thing that came into my head…different types of homes is what I’m going with.
Let’s start with a blueprint (or class) for a Home. I don’t want this to be too complicated but going too trivial may not get the key points across, so hopefully this middle ground will make sense:
/// <summary>
/// The blueprint, in our application, for a place
/// to live.
/// </summary>
public class Home
{
#region Private Readonly Data Fields
/// <summary>
/// Every home is expected to have rooms. This value, as it's marked
/// as readonly, can only be set with a value here as part of the declaration or
/// as part of a 'constructor' (that is involved in building an instance of a home) - in this
/// first iteration the number of rooms in a home isn't going to change (we'll come back to this!).
/// </summary>
private readonly int numberOfRooms;
#endregion Private Readonly Data Fields
#region Private Data Fields
/// <summary>
/// A private variable that keeps track of whether the
/// door to the home is open or closed. The door to a home
/// can only be opened/closed by triggering the OpenDoor/CloseDoor
/// methods on an 'instance' of the type, no direct
/// access is allowed = encapsulation.
/// </summary>
private bool doorOpen = false;
#endregion Private Data Fields
#region Public Properties
/// <summary>
/// Allow an object user to get a value representing if a home's
/// door is open or closed, without allowing them to directly
/// change the state of the door.
/// </summary>
public bool IsDoorOpen
{
get
{
return doorOpen;
}
}
/// <summary>
/// Much like with IsDoorOpen, allow an object user to get a
/// readout of the number of rooms in this home without any direct
/// access to change it at this point (and the underlying variable
/// is currently readonly anyway, disallowing changes at this time).
/// </summary>
public int NumberOfRooms
{
get
{
return numberOfRooms;
}
}
#endregion Public Properties
#region Constructor
/// <summary>
/// The 'constructor' for a Home that is used to setup object
/// state for each and every instance of a home.
/// </summary>
/// <param name="roomCount">The number of rooms that are in this house (provided by the object user).</param>
public Home(int roomCount)
{
numberOfRooms = roomCount;
}
#endregion Constructor
#region Public Methods
/// <summary>
/// Public method that triggers an action on this home, i.e. opens
/// the door of this home.
/// </summary>
public void OpenDoor()
{
// Opens the door to the house
doorOpen = true;
// Perhaps other things happen as a result of this...
Console.WriteLine("The door on this home has been opened.");
}
/// <summary>
/// Public method that triggers an action on this home, i.e. closes
/// the door of this home.
/// </summary>
public void CloseDoor()
{
// Closes the door to the house
doorOpen = false;
// Perhaps other things happen a result of this...
Console.WriteLine("The door on this home has been closed.");
}
#endregion Public Methods
}
I’ve outlined the starting concept of what I think a ‘Home’ looks and feels like. A home has, from my very barebones view (forgetting about things like walls, ahem!):
- A number of rooms.
- A door.
- A way for the door to be opened and closed.
Obviously, homes are far more complicated than this, but this will get us going. Regardless of the keywords and definitions used this is nothing more than a blueprint, an instance of an object is required to start interacting with a home, as follows:
/// Create an instance of a home, using the blueprint provided, and open
/// then close the door (as well as read out the number of rooms).
/// </summary>
private static void PlayWithAHome()
{
// Use the 'Home' class blueprint to create an 'instance' of a Home so we can actually start reading/triggering facets of it
// The Home blueprint demands, in this case, that we provide the number or rooms (as part of the constructor)
Home testHome = new Home(6);
// Let's use our home...
Console.WriteLine($"The home has { testHome.NumberOfRooms } rooms."); // How many rooms does the home have
Console.WriteLine($"The door is { (testHome.IsDoorOpen ? "open" : "closed") }."); // Is the door open or closed (should start closed)
// Let's open the door (we should get a console readout as part of triggering this functionality on a Home)
testHome.OpenDoor();
Console.WriteLine($"The door is now { (testHome.IsDoorOpen ? "open" : "closed") }."); // Is the door open or closed (should now be open)
// Stop the application so we can read the output
Console.Read();
}
A simple run through then; a home has a blueprint that defines it will contain a certain number of rooms, a door, a way to read out the number of rooms and whether the door is ajar (private fields and properties) and a mechanism for opening and closing the door (methods). This is the class (or type). To actually get a readout on the number of rooms and start opening and closing the door we need to build the home, end of; this is the instance.
There are a few extra comments in the Home class that discuss ‘readonly’ variables, ‘getter only’ properties (which ties in encapsulation) and the constructor; I’ll leave you to peruse them as I’ve covered the meat of classes and instances at this point.
Sideline question…how does inheritance come into this
Just before my poor Mum looked destined to snooze off at the dinner table, meaning for everyone’s sanity the subject had to be changed, we also skimmed inheritance; so I’ll give one brief example below using our ‘Home’ class from before (modified to make it simpler this time around).
Inheritance, in short, is the idea of building a ‘chain’ of related classes, by building common functionality into a ‘base’ class and then reusing/overriding this functionality in one or more sub-classes; basically, new classes can be created using an existing class as a starting point. The core concept behind classical inheritance is the ‘is a’ relationship between types; below we have a one man tent, bungalow and house; these can all be prefixed with the term ‘is a’ to establish a valid sounding relationship (a house ‘is a’ home, for example).
Firstly, although not required for inheritance, I’ve created an interface, or contract, that outlines the common functionality that any implementing class must define (and subsequently, will be tied to subclasses). This wasn’t mandatory for the example I was putting together but I’ve opted to roll with it.
namespace HomeApplication
{
/// <summary>
/// Public interface that defines the properties and behaviours
/// that all homes should exhibit. The Home class will use this interface
/// that basically states that the class will implement the described properties/methods -
/// This can be thought of as a contract (a promise that the facets will be found on the class).
/// </summary>
public interface IHome
{
/// <summary>
/// Homes all have a certain number of floors, or living 'levels'.
/// </summary>
int NumberOfFloors { get; }
/// <summary>
/// Homes all have a certain number of rooms.
/// </summary>
int NumberOfRooms { get; }
/// <summary>
/// Homes all have a way to tell if the door is open or closed.
/// </summary>
bool IsDoorOpen { get; }
/// <summary>
/// Homes (for my example) are expected to have a way to open the door.
/// </summary>
void OpenDoor();
/// <summary>
/// Homes (for my example) are expected to have a way to close the door.
/// </summary>
void CloseDoor();
/// <summary>
/// Homes (for my example) are expected to have a way to turn on the heating.
/// </summary>
void TurnOnHeating();
}
}
Using our IHome interface, the Home class outlines common functionality and properties to be shared by all subclasses; we are ultimately just using, as stated before, this class as a starting point to create other classes.
This class has been listed as abstract (which is not a requirement for implementing inheritance), which means that a ‘Home’ is an abstract concept only and I want to disallow users from creating an instance of this type; only instances of subclasses should be created. In as short a description as possible, virtual members provide a default implementation but can be optionally overridden by subclasses, abstract members, however, require subclasses to provide the full implementation (we are simply stating, in this case, that subclasses should implement a particular flavour of functionality). Other than that, I’ve described other pertinent details in the comments within the class definition itself.
using System;
namespace HomeApplication
{
/// <summary>
/// The blueprint, in our application, for a place
/// to live. This is 'abstract', meaning no one can create
/// a home as an instance to use directly, they can only create
/// sub-classes of 'Home' for use in an application.
/// </summary>
public abstract class Home : IHome // IHome defines a contract that 'Home' has to conform to (and therefore, that all sub-classes will be locked in to)
{
#region Public Properties
/// <summary>
/// Allow an object user to read the number of floors
/// in this home (this value can only be set privately
/// within this class, not from another class or sub-class directly).
/// </summary>
public int NumberOfFloors { get; private set; }
/// <summary>
/// Allow an object user to read the number of rooms
/// in this home (this value can only be set privately
/// within this class, not from another class or sub-class directly).
/// </summary>
public int NumberOfRooms { get; private set; }
#endregion Public Properties
#region Public Virtual Properties
/// <summary>
/// Allow an object user to obtain a value that represents if
/// the door is open or closed. This is virtual as I want to allow
/// derived types to optionally override how this is determined.
/// </summary>
public virtual bool IsDoorOpen { get; private set; }
#endregion Public Virtual Properties
#region Constructor
/// <summary>
/// When an 'instance' of a home is created we expect
/// to be provided with the number of floors and rooms
/// available within the home.
/// </summary>
/// <param name="floors">The default number of floors on offer.</param>
/// <param name="rooms">The default number of rooms on offer.</param>
public Home(int floors, int rooms)
{
// Store the provided values in the appropriate properties
NumberOfFloors = floors;
NumberOfRooms = rooms;
}
#endregion Constructor
#region Protected Methods
/// <summary>
/// Protected members or only accessible from within this type and from direct
/// descendant types, not from an external class. I want sub-types to possibly alter
/// how many rooms (by adding a room) can be found in the home.
/// </summary>
/// <param name="numberOfRooms">The number of rooms to add.</param>
protected void AddExtraRooms(int numberOfRooms)
{
NumberOfRooms += numberOfRooms;
}
#endregion Protected Methods
#region Public Virtual Methods
/// <summary>
/// Public virtual method that closes a home's door - this represents
/// the 'default' implementation only. This is virtual as I want derived
/// classes to be able to optionally override how this process
/// happens (see the OneManTent, for example).
/// </summary>
public virtual void CloseDoor()
{
// Closes the door to the house (enhanced to fully use auto properties)
IsDoorOpen = false;
// Perhaps other things happen a result of this...
Console.WriteLine("The door on this home has been closed.");
}
/// <summary>
/// Public virtual method that opens a home's door - this represents
/// the 'default' implementation only. This is virtual as I want derived
/// classes to be able to optionally override how this process
/// happens (see the OneManTent, for example).
/// </summary>
public virtual void OpenDoor()
{
// Opens the door to the house (enhanced to fully use auto properties)
IsDoorOpen = true;
// Perhaps other things happen as a result of this...
Console.WriteLine("The door on this home has been opened.");
}
#endregion Public Virtual Methods
#region Public Abstract Methods
/// <summary>
/// Final method...this is abstract as we are enforcing a situation whereby derived
/// types of 'Home' have to implement this themselves (every home's method of heating will
/// vary in my test setup) - there is no default implementation.
/// </summary>
public abstract void TurnOnHeating();
#endregion Public Abstract Methods
}
}
Our other classes are utilising inheritance directly, using the Home class as a ‘template’ and using ‘overrides’ where applicable to provide their own spin on functionality, as required.
For example, all types support opening and closing of the door; however, tents override this functionality to take the ‘zip getting stuck’ into account. Houses allow for extensions to be built, which ultimately means that further rooms get added to the home. Further in line comments are there for more in-depth explanations as to what is going on.
using System;
namespace HomeApplication
{
/// <summary>
/// Blueprint that defines what a house looks like
/// (this 'is a' home in my example).
/// </summary>
public class House : Home // A house 'is a' home, but has some differences, which this class outlines
{
#region Constructor
/// <summary>
/// The constructor for a house consumes values that represent
/// the number of floors and rooms that are available - these are passed
/// directly to the Home base classes constructor.
/// </summary>
/// <param name="floors">The default number of floors on offer.</param>
/// <param name="rooms">The default number of rooms on offer.</param>
public House(int floors, int rooms)
: base(floors, rooms)
{
}
#endregion Constructor
#region Public Methods
/// <summary>
/// This method is house specific, in my example (could apply to a bungalow, of course, but
/// I've opted to not allow this for now). A house can have an extension added by calling the protected
/// (only accessible from the Home class or derived types, like this 'House') AddExtraRooms method. The room
/// count for this House will therefore be increased by one.
/// </summary>
public void AddAnExtension()
{
Console.WriteLine("Adding an extension to the house (+1 rooms).");
AddExtraRooms(1);
}
#endregion Public Methods
#region Public Overridden Methods
/// <summary>
/// This represents what happens when the heating is turned on in a house
/// (remember, this was marked as abstract on the base class so this class
/// has no choice but to offer up some kind of implementation). Super toasty
/// central heating is on offer here!
/// </summary>
public override void TurnOnHeating()
{
Console.WriteLine("Turning on the central heating in the house.");
}
#endregion Public Overriden Methods
}
}
using System;
namespace HomeApplication
{
/// <summary>
/// Blueprint that defines what a bungalow looks like
/// (this 'is a' home in my example).
/// </summary>
public class Bungalow : Home // A bungalow 'is a' home, but has some differences, which this class outlines
{
#region Constructor
/// <summary>
/// The constructor for a bungalow consumes a value that represent
/// the number of rooms that are available - this is passed
/// directly to the Home base classes constructor. Notice that we are internally
/// setting the amount of floors to 1 (illustration only, to show how a derived type
/// can take control of it's own state).
/// </summary>
/// <param name="rooms">The default number of rooms on offer.</param>
public Bungalow(int rooms)
: base(1, rooms) // Bungalows - we only allow a single floor in our example
{
}
#endregion Constructor
#region Public Overridden Methods
/// <summary>
/// This represents what happens when the heating is turned on in a bungalow
/// (remember, this was marked as abstract on the base class so this class
/// has no choice but to offer up some kind of implementation). A Coal fire
/// have been selected as the weapon of choice in this case.
/// </summary>
public override void TurnOnHeating()
{
Console.WriteLine("Lighting up the coal fire in the bungalow.");
}
#endregion Public Overriden Methods
}
}
using System;
namespace HomeApplication
{
/// <summary>
/// Blueprint that defines what a one man tent looks like
/// (this 'is a' home in my example).
/// </summary>
public class OneManTent : Home // A one man tent 'is a' home, but has some differences, which this class outlines
{
#region Public Properties
/// <summary>
/// The door for a tent has an added element to worry about...the bloody zip!
/// If the zip is broken the door (in my example) is classed as stuck open, might not
/// be true to reality but serves as illustrative only.
/// </summary>
public bool IsZipBroken { get; set; }
#endregion Public Properties
#region Public Overridden Properties
/// <summary>
/// Overriden functionality from the 'Home' base class. If the zip is broken
/// the door is classed as open. If the zip isn't broken we simply read if the door
/// is open or closed from the base class.
/// </summary>
public override bool IsDoorOpen
{
get
{
return IsZipBroken ? true : base.IsDoorOpen;
}
}
#endregion Public Overridden Properties
#region Constructor
/// <summary>
/// The constructor for a one man tent consumes a value that represent
/// the number of rooms that are available - this is passed
/// directly to the Home base classes constructor. Notice that we are internally
/// setting the amount of floors to 1 (illustration only, to show how a derived type
/// can take control of it's own state).
/// </summary>
/// <param name="rooms">The default number of rooms on offer.</param>
public OneManTent(int rooms)
: base(1, rooms) // Tents - we only allow a single floor in our example
{
}
#endregion Constructor
#region Public Overridden Methods
/// <summary>
/// A tent overrides how a the door is opened. If the zip is broken the tent
/// door is stuck open. Otherwise, the door opens as normal (via functionality
/// found on the 'base' class).
/// </summary>
public override void OpenDoor()
{
if (!IsZipBroken)
{
// Zip is not stuck, open the door as normal
base.OpenDoor();
}
else
{
// The zip is stuck!!!
Console.WriteLine("The zip is broken so the tent door is stuck open");
}
}
/// <summary>
/// A tent overrides how a the door is closed. If the zip is broken the tent
/// door is stuck open. Otherwise, the door opens as normal (via functionality
/// found on the 'base' class).
/// </summary>
public override void CloseDoor()
{
if (!IsZipBroken)
{
// Zip is not stuck, close the door as normal
base.CloseDoor();
}
else
{
// The zip is stuck!!!
Console.WriteLine("The zip is broken so the tent door is stuck open");
}
}
/// <summary>
/// This represents what happens when the heating is turned on in a one man
/// tent (remember, this was marked as abstract on the base class so this class
/// has no choice but to offer up some kind of implementation). Hot water bottles
/// are the only choice here!
/// </summary>
public override void TurnOnHeating()
{
Console.WriteLine("Urm...using the hotwater bottle for extra heat!");
}
#endregion Public Overriden Methods
}
}
/// <summary>
/// Further fun and games with homes!
/// </summary>
private static void PlayWithHomes()
{
// A House, Bungalow and OneManTent are 'Homes', therefore share some of the blueprint information (as they are derived classes). Let's use them, and explore the differences
// Configure instances, with floor and room numbers, as available to us
House myHouse = new House(2, 8);
Bungalow myBungalow = new Bungalow(7);
OneManTent myTent = new OneManTent(2);
// 1) The House...
Console.WriteLine("Details about myHouse..." + Environment.NewLine);
Console.WriteLine($"The house has { myHouse.NumberOfRooms } rooms.");
Console.WriteLine($"The house has { myHouse.NumberOfFloors } floors.");
Console.WriteLine($"The house door is { (myHouse.IsDoorOpen ? "open" : "closed") }.");
// Open the door and check the door state
myHouse.OpenDoor();
Console.WriteLine($"The house door is { (myHouse.IsDoorOpen ? "open" : "closed") }.");
// Turn on the heating in the house
myHouse.TurnOnHeating();
// Add an extension (house specific)
myHouse.AddAnExtension();
Console.WriteLine($"The house has { myHouse.NumberOfRooms } rooms (after adding an extension)." + Environment.NewLine);
// ---------------------------------------------------------------------------------------------------
// 2) The Bungalow...
Console.WriteLine("Details about myBungalow..." + Environment.NewLine);
Console.WriteLine($"The bungalow has { myBungalow.NumberOfRooms } rooms.");
Console.WriteLine($"The bungalow has { myBungalow.NumberOfFloors } floor.");
Console.WriteLine($"The bungalow door is { (myBungalow.IsDoorOpen ? "open" : "closed") }.");
// Open the door and check the door state
myBungalow.OpenDoor();
Console.WriteLine($"The bungalow door is { (myBungalow.IsDoorOpen ? "open" : "closed") }.");
// And close it this time, for good measure
myBungalow.CloseDoor();
Console.WriteLine($"The bungalow door is { (myBungalow.IsDoorOpen ? "open" : "closed") }.");
// Turn on the heating in the bungalow
myBungalow.TurnOnHeating();
Console.WriteLine();
// ---------------------------------------------------------------------------------------------------
// 3) The One Man Tent...
Console.WriteLine("Details about myTent..." + Environment.NewLine);
Console.WriteLine($"The tent has { myTent.NumberOfRooms } rooms.");
Console.WriteLine($"The tent has { myTent.NumberOfFloors } floor.");
Console.WriteLine($"The tent door is { (myTent.IsDoorOpen ? "open" : "closed") }.");
// Let's break the zip!
myTent.IsZipBroken = true;
// Open the door and check the door state (it should be stuck open)
myTent.OpenDoor();
Console.WriteLine($"The tent door is { (myTent.IsDoorOpen ? "open" : "closed") }.");
// And close it this time, for good measure
myTent.CloseDoor();
Console.WriteLine($"The tent door is { (myTent.IsDoorOpen ? "open" : "closed") }.");
// Fix the zip and try to re-open and close the door
myTent.IsZipBroken = false;
myTent.OpenDoor();
Console.WriteLine($"The tent door is { (myTent.IsDoorOpen ? "open" : "closed") }.");
myTent.CloseDoor();
Console.WriteLine($"The tent door is { (myTent.IsDoorOpen ? "open" : "closed") }.");
// Turn on the heating in the tent
myTent.TurnOnHeating();
// Stop the application so we can read the output
Console.Read();
}
Finally, the following diagram shows that tents, bungalows and houses ‘are’ homes; they share the common facets of a home whilst providing their own functionality and overridden logic, that’s essentially it!
I’ll do a more in depth OOP principle post in the future so watch this space.
Happy Easter!!!
bearandhammer 