The When and Why: Properties and Fields

Fields and Properties are two important concepts that come up very early on when learning to code. Due to their surface level similarities it can be a confusing process understanding when to use each of them and why.

When?

Only ever use fields with the private access modifier. They can be used with protected or public but it's generally poor practice and I'll explain why later.

Use properties for all non-private scenarios, even if the properties are auto-implemented. You can also use them in a private context when implementing get and set logic.

public class ExampleClass
{
    // This particular field is used as a 'backing' field
    // for PropertyWithLogic
    private int _myField;

    // protected, so a property, even though its an auto-property
    protected string AutoProperty { get; set; } 

    // private but has logic, so a property
    private int PropertyWithLogic
    {
        get { return _myField; }
        set { _myField = value >= 0 ? value : 0; } 
    }
}

Why?

Good Object Oriented Programming is all about encapsulation, separating the interface of a class from its implementation. Interfaces are the blueprints for what a class should do, Classes are the how it does it.

The signature and implementation of a field are inseparable. That is to say, there is no separation of the what of a field (getting and setting of a value) from the how of a field (storing the value in memory). For this reason, fields are an implementation detail and can't be part of an interface.

Properties, on the other hand, separate signature from implementation. In the below example, the interface specifies that implementations must provide a property that you can get and it's the classes that define how that property is implemented.

public interface IExample
{
    string Description { get; }
}

public class Example1 : IExample
{
    // Returns a hard-coded string.
    public string Description
    {
        get { return "Example1"; }
    }
}

public class Example2 : IExample
{
    private int _id;
    private DateTime _createdDate;

    // Performs some logic to return a string
    // that includes some member field values.
    public string Description
    {
        get 
        { 
            return string.Format(
                        "Example2, id: {0}, created: {1}",
                        _id,
                        _createdDate); 
        }
    }
}

public class Example3 : IExample
{
    // Not implemented. Throws an exception when accessed.
    public string Description
    {
        get 
        { 
            throw new NotImplementedException("Todo!");
        }
    }
}

public class Example4 : IExample
{
    // Auto-property implementation, will return whatever
    // we set the value to.  Value is stored in an
    // automatically generated backing field.
    public string Description { get; set; }
}

Keeping interfaces separate from implementation in this way is a critical step in keeping the code you are writing from collapsing under its own weight over time.

An additional reason to use public automatic properties rather than public fields is that should you later need to add logic to the getter or setter, swapping from a field to a property is a breaking change for serialization as well as being a breaking change for backwards compatibility between dependent assemblies. Taking the time to do it right now will save you unnecessary difficulty when the application has grown or live data is involved.

Further Reading

This post has been all about fields versus properties, but it's worth noting that there's also a separate and equally important discussion of properties versus methods. Check out this excellent MSDN article comparing properties and methods.

I mention variations on the following topics in almost all Further Readings because understanding them inside and out means the difference between writing code that works and writing code that works and stands the test of time.

• The four pillars of Object Oriented Programming
• The principles of SOLID

Even if you disagree with elements of generally accepted object oriented programming theory and go your own route, it's still an invaluable asset to have and I strongly recommend taking the time to assimilate it.

The When and Why: Dependency Injection

Dependency Injection is one form of Inversion of Control - a collection of programming patterns focused on minimising your classes' direct reliance on each other, known as their coupling.

In its simplest form Dependency Injection just means to provide an object its dependencies instead of having the object create them for itself.

When?

In any class where you use the new keyword to instantiate another class, you should think about using Dependency Injection instead. It may feel like overkill at first but the benefits are big and get bigger as the application grows in size.

Here's a real world before and after example and I'll explain the why of it straight after.

BEFORE

public class CustomerService
{
    private const string SqlConnectionString = 
         @"server=localhost;username=admin;password=password;";

    private const string LoggingFilePath = 
         @"C:\logs\MyApplication.txt";

    private readonly ILogger _logger;
    private readonly IDataContext _context;

    public CustomerService()
    {
        // In this example all of the services create
        // their own logger and data context instance when
        // they are created.
        // The classes FileLogger and SqlDataContext are this
        // class's 'dependencies' because they are needed in 
        // order for this class to compile.
        _logger = new FileLogger(LoggingFilePath);
        _context = new SqlDataContext(SqlConnectionString);
    }

    public IEnumerable<Customer> GetCustomers(int accountID)
    {
        // TODO: Use logger to log
        // TODO: Use context to get customers for account ID
    }
}

public static class Application()
{
    public static void Main()
    {
        var service = new CustomerService();
        foreach (var customer in service.GetCustomers(55))
        {
            Console.WriteLine(customer.Name);
        }
    }
}

AFTER

public class CustomerService
{
    private readonly ILogger _logger;
    private readonly IDataContext _context;

    public CustomerService(IDataContext context, ILogger logger)
    {
        // In this example instead of instantiating the 
        // dependencies themselves, the service classes like 
        // CustomerService expect them to be passed in.
        // Taking them via the constructor is known as 
        // 'Constructor Injection' and is the preferred method
        // of Dependency Injection because it forces the
        // developer to provide the right dependencies before
        // the class can be used.
        _logger = logger;
        _context = context;
    }

    public IEnumerable<Customer> GetCustomers(int accountID)
    {
        // TODO: Use logger to log
        // TODO: Use context to get customers for account ID
    }
}

public static class Application()
{
    private const string SqlConnectionString = 
         @"server=localhost;username=admin;password=password;";

    private const string LoggingFilePath = 
         @"C:\logs\MyApplication.txt";

    public static void Main()
    {
        // This is messier than it was but the mess is now in
        // a single location which can be easily tightened up 
        // using a DI framework such as Ninject or Unity.
        var logger = new FileLogger(LoggingFilePath);
        var context = new SqlDataContext(SqlConnectionString);
        var service = new CustomerService();
        foreach (var customer in service.GetCustomers(55))
        {
            Console.WriteLine(customer.Name);
        }
    }
}

Why?

There are many convincing reasons to follow the Dependency Injection pattern, I'll cover a few of them here.

Implementation Agnosticism

The before example enforces the use of SqlDataContext and FileLogger. It doesn't need those specific implementations to work properly, it actually just needs something that implements IDataContext and something that implements ILogger in order for it to perform its responsibility of getting the customers, but the implementation in before has specified a concrete implementation anyway.

If we wanted one Customer Service in our application to log to a file and another to log to a database, the pattern in before would force us to either copy paste the whole class to make this small change or start specifying different enums or booleans to pick a context Type on the constructor and, as a result, would seriously harm the scalability of the application by coupling this class with every implementation it could possibly be used with.

The Customer Service in the after example is much more flexible because it does not arbitrarily restrict us to working with certain implementations of the interface. The class definition is also much clearer about exactly what the Customer Service needs in order to function correctly and also what it's purpose is: Getting customers from any given IDataContext and logging about it.

Avoiding unnecessary usage restrictions and minimising Class Coupling like this is the key to developing maintainable systems that don't become exponentially more complicated to work with as the codebase grows.

Single Responsibility Principle

Having a single responsibility makes the class more likely to be reusable, more accessible and more easily tested. Beyond making the programmer's life easier there's a structural benefit to the Single Responsibility Principle too.

CustomerService Responsibilities Before	CustomerService Responsibilities After
Create Log File Connection	Getting the Customers
Create Database Context
Getting the Customers

We can't open the same file twice, so to share a FileLogger between classes using the approach in before we'd have to make the logger available as a public static. If we ever need to change the SQL connection string for the application, we'd have to make sure we update it in all locations or make the connection string a static variable, too.

You might be tempted to resolve these sorts of issues by making everything static and publicly available but making everything public and static is an anti-pattern and doesn't resolve the issue anyway, it just hides the issue long enough for you to write a few thousand more lines of code before reaching a scenario it can't handle.

An example of such a scenario would be needing the logger and data context to live longer than a customer service but not forever and not globally across the application - for the duration of an individual web request, for instance.

Managing the lifespan of class instances as a separate responsibility and injecting them into their dependents keeps code from being bogged down under ever-changing business requirements.

Unit Testing

Unit Testing is the act of testing individual units of functionality in your code to prove that specific expectations are met. For example, a useful Unit Test for CustomerService would be GetCustomers Gets Only Customers For Provided Account, where we test to ensure that the implementation only retrieves customers with a matching account ID.

Because we don't control which ILogger and IDataContext implementations the Customer Service gets in the before example, if we were to test GetCustomers then we'd be including the workings of SqlDataContext and FileLogger within that test too. If the SQL database has the wrong data or FileLogger had a bug, then the GetCustomers Gets Only Customers For Provided Account test would fail, even if the core logic of GetCustomers is correct.

A good Unit Test tests a small, specific unit of code. In the after example, we can pass in whatever implementations of ILogger and IDataContext best suit our needs. In the real code, we provide a SqlDataContext and FileLogger. In the Unit Test, however, we can provide an implementation of ILogger that does nothing and an IDataContext implementation that provides a specific set of records for testing whether GetCustomers does its job properly given that data.

Unit Testing is very much a topic in its own right. It's well worth getting an understanding.

Further Reading

The topics touched upon in this post are well worth investigating in the own right. Here are a few links to articles that provide a broader understanding of them individually and I recommend searching for as much information as you can find on each of them.

• Cohesion and Coupling
• Single Responsibility Principle
• Unit Testing

A Challenge

See if you can write an entire application where the new keyword is used in only one class and all other classes have their dependencies injected via their constructor!

The When and Why: Static

The static modifier, much like the access modifiers, is one of the first keywords that new developers learn and, much like the public access modifier, static is often misused by new developers because it provides a seemingly easy shortcut around learning how to write proper Object Oriented code.

Excessive use of the static modifier can lead to messy, overly complex code. On the other hand, careful use of the static modifier can lead to functionality that is elegant, scalable and performs well. The aim of this article is to help new developers strike the right balance. First I'll describe when to use static, then I'll explain why.

When?

Ideally, static should only be used for private or protected members when you need to share a single value between all instances of the class to which those members belong. You should avoid using public static wherever possible.

There are a couple of occasions where a public static is required, however.

Providing Common Values for structs

If you've ever used string.Empty or int.MinValue then you've invoked a public static property. Here's an example of using the same technique in a Point struct.

public struct Point
{
    public int X;
    public int Y;

    // Static property that returns an instance of point
    public static Point Zero 
    {
        return new Point { X = 0, Y = 0 };
    }
}

// This...
var point = Point.Zero; 

// ...is cleaner and more descriptive than writing this...
var point = new Point { X = 0, Y = 0 };

// ...every time we want a zero value point

Extension Methods

Extension methods are a way to add new functionality to classes that you don't have access to the code for. The design pattern for extension methods requires that you use the static modifier on a public method.

public static class StringExtensions
{
    public static string Left(this string str, int count)
    {
        return str.Length <= count 
               ? str 
               : str.SubString(0, count);
    }
}

// We use the extension method just like any normal method
var example = "Hello world".Left(5);

Why?

Over-use of the static modifier is an anti-pattern because it increases and actually encourages class coupling. Code that features classes that reference each other excessively is often referred to as spaghetti code because of how difficult it is to untangle and understand.

When all of your classes know about each other in this way they become less reusable and they also become harder to maintain. After all, it's much easier for you as a programmer to understand and reuse a class that only knows about itself than it is to understand one that accesses eight or nine other classes, each of which accesses another eight, and so on.

Further Reading

I encourage you to read up on all of the below topics as even a loose understanding in the back of your mind will have you start asking the right questions when writing code.

SOLID, Class Coupling, Cohesion, Interfaces, Factory Pattern, Dependency Injection

Understanding programming theory really is just as important as understanding syntax. If you have any questions at all about these subjects, feel free to drop me an e-mail or ask straight in the comments.

The When and Why: For and Foreach

I've often seen it asked which type of loop out of for and foreach is more appropriate under a given set of circumstances. I'll explain when to use each type of loop, then I'll explain the why, much in the same way that I did for access modifiers.

Definitions

The keywords for and foreach have such broad applications that it can be a bit befuddling trying to understand what all the related terms mean. Below is a quick summary of the terms I'll be using.

• Enumerable: An object that can be enumerated (it implements IEnumerable). Don't worry if that's too technical, just know that you can use foreach with any object that is enumerable (i.e. all arrays and collections).
• Enumerate: To go through each item in an Enumerable in turn.
• Index: An item's zero-indexed position in the collection/array. e.g. items[3] is the 4th item in the array named 'items'.

Note: Not all enumerables have an index, but anything with an index is enumerable.

When

Always start with foreach, you can swap to for later if the need arises. You can't add or remove items in a collection while enumerating it, but you can call methods and get/set properties on the item, which is the most common reason for enumerating.

foreach (var item in items)
{
    item.DoWork();
    item.Property = "Some other value";
}

Use for only when you need access to the current index and are working with an array or array-based collection (e.g. a list). One scenario that you might need this is when you need to remove items from a collection while going through it (something you can't easily achieve with foreach). Here's an example.

// go through the list backward so that removing 
// items doesn't cause us to skip the item that follows.
for (int i = myList.Count - 1; i >= 0; --i) 
{
    if (myList[i].ShouldBeRemovedFromList)
    {
        myList.RemoveAt(i);
    }
}

Why

There are many technical reasons for favouring foreach over for, but my main reason isn't technical at all. foreach is fewer lines of code, uses cleaner syntax and also expresses the intent of your code. That is, 'go through this collection without changing which items are in the collection'.

As luck would have it, foreach isn't just better looking, it often performs better too!

As mentioned in the definitions section, not all enumerables have an index, but all objects with an index can be enumerated. Similarly, arrays have length and some collections have Count, but some implementations of enumerable have neither. You'd be tempted to cheat and use the extension method Count(), but that'd be a mistake. Why? Let's take a look at a comparison.

// foreach on an enumerable
foreach (var item in items)
{
    if (item.GiveUp)
        break;
}

// for loop on enumerable
// Count() extension method is not the same as List<T>'s Count
for (int i = 0; i < items.Count(); ++i) 
{
    if (items[i].GiveUp)
        break;
}

You'd be forgiven for thinking that the two examples do the same thing and, from the perspective that they achieve the same result, they do. However, the second example is actually a performance issue waiting to happen.

Let's say that the enumerable items has 10,000 items in it and that it is the 5th item of those 10,000 that gives up.

• First example: We enumerate the first five items, reach the item that indicates we should give up and exit the loop (by using the break keyword).
• Second example: We do the same thing, except that the call to the extension method Count() actually goes through the whole enumerable and counts all the items before we start.

So while the foreach example makes 5 visits, the for example makes 10,005... That's a pretty massive difference!

This is just one example and there are many more where foreach is the smarter choice, but this article is quite long already, so if you have any specific scenarios you're not sure about then let me know in the comments and I'll add them to the article.

Further Reading

There are occasions when you'll want to run a loop until a particular condition is met, rather than running a loop for every item in an array or collection. When such an occasion arises, you'll be glad to know about the while statement.

If you're interested in the fine-grained difference between an array and a collection then check out this MSDN article on Arrays and Collections.

foreach and the yield keyword go hand in hand. It's the yield keyword that lets you enumerate a collection or array once, instead of once per method that does work on it.

I've saved the best for last, as once you have a handle on the basics of foreach and yield it's well worth getting to grips with using LINQ. It can be quite a big topic with lots of confusing and varied applications, but hopefully these two hints will help make things clearer.

1. LINQ does different things depending on what you use it on. For example, using LINQ on an in memory list will run code against the list, using it on a LINQ to SQL table object will generate and execute SQL against the database!
2. LINQ makes use of a concept known as Lazy Evaluation, which means that the aforementioned generation and code running doesn't happen until you actually enumerate the collection.

If you'd like to see a beginner's guide to LINQ, let me know in the comments, as I'd love to write one!

The When and Why: Access Modifiers

Today I'm going to talk about access modifiers. If you don't know what they are or how to use them, check out the first section of this MSDN topic.

Read it? Understood it enough to get a program to compile? Great, then lets get to it. I'll start with the when, then explain the why.

When?

Use private first for anything that other classes don't need to see. You can always make something protected or public later but, when you do, ask yourself if there's a way you can keep it private and expose the work you want to do with the private fields as a public method instead of exposing the fields directly.

Public should be used only when absolutely necessary. For example, if you find yourself writing something like this:

public class PersonDetails
{
    public int Age { get; set; }
    public DateTime Birthday { get; set; }
    public bool IsFemale { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime WeddingDate { get; set; }
}
 
static void Application_Main()
{
    var person = new PersonDetails();
    person.FirstName = "Jane";
    person.LastName = "Bloggs";
    person.IsFemale = true;
    person.Birthday = new DateTime(1984, 10, 24);
    person.Age = 
        (DateTime.Now - new DateTime(1984, 10, 24)).Years;
    
    if (justMarried)
    {
        if (person.IsFemale)
        {
            person.LastName = "Sanders";
        }

        person.WeddingDate = DateTime.Now;
    }

    Console.WriteLine(
            person.FirstName 
            + " " 
            + person.LastName 
            + " is " 
            + person.Age);
}

Then you should get in the habit of thinking "that's a lot of person-dot-somethings, this would be better off as private fields and a public method" and rearrange it to be a bit more like this:

public class PersonDetails
{
    public int Age 
    {
        get 
        { 
            return (DateTime.Now - _birthday).Years; 
        } 
    }

    public string FullName 
    { 
        get 
        { 
            return _firstName + " " + _lastName; 
        } 
    }

    private DateTime _birthday;
    private string _firstName;
    private string _lastName;
    private bool _isFemale;
    private DateTime _weddingDate;

    public PersonDetails(
                string firstName, 
                string lastName, 
                DateTime birthday, 
                bool isFemale)
    {
        _firstName = firstName;
        _lastName = lastName;
        _birthday = birthday;
        _isFemale = isFemale;
    }

    public void JustMarried(string newLastName)
    {
        if (_isFemale)
        {
            _lastName = newLastName;
        }

        _weddingDate = DateTime.Now;
    }
}
 
static void Application_Main()
{
    var person = new PersonDetails(
                        "Jane", 
                        "Bloggs", 
                        new DateTime(1984, 10, 24), 
                        true);

    if (justMarried)
    {
        person.JustMarried("Sanders");
    }

    Console.WriteLine(person.FullName + " is " person.Age);
}

You probably won't stop there, because once everything is sorted, it'll be easier to see other improvements you can make. This process of improvement is called refactoring and it is an important and iterative process - meaning you do it over and over. Your classes will end up looking a lot more descriptive, useful and less error prone if you get into this habit.

Use protected when you're inheriting from your class and need access in the child class to methods and properties that exist in the parent class but aren't public.

You probably won't need internal for now as it's mostly used in third party libraries to create classes that are public to their code, but hidden from yours.

Why?

Good Object Oriented Programming is all about encapsulation. Encapsulation just means that your objects (that's the classes and structs you write) are self-contained. A good object hides how it does something and only publicly exposes enough methods and properties to cover what it does.

Exposing the bare minimum functionality publicly to other classes promotes readability, it also promotes re-usability (the code is in a neat little package that doesn't rely on dozens of other classes) and it promotes scalability. It's also less likely to have errors in it because being all packaged nicely means it's easier for you to keep track of and - if you do make a mistake - it'll be easier to figure out what's going wrong, because there are fewer elements to your code that could be affecting a private field or property compared to a public one.

Let's take a side by side look at the public members of our example before and after we refactored it.

Before	After
Age (get / set)	Age (get only)
Birthday (get / set)	FullName (get only)
IsFemale (get / set)	JustMarried()
FirstName (get / set)
LastName (get / set)
WeddingDate (get / set)

As you can see, the list on the right is a lot shorter and tells us how we're expected to use the class without having to dig around inside of it or find out how everything else is using it. In big projects, well designed classes that let you understand the what without the how become the difference between it taking 10 minutes to change something and 10 hours. You'll come to find that well structured code also helps you feel more confident that your change isn't secretly breaking something somewhere else!

Further Reading

If this topic has you chomping at the bit for more, then you should check out the readonly keyword. In the same way that private protects from public misuse, readonly protects from after-construction misuse.

You should also definitely check out Interfaces. Interfaces don't have any implementation (implementation is what we call the how in programming). Their purpose is to define the contract (the what) that a class must fulfill publicly in order to be considered an implementation of that interface. If you'd like to see a W&W article on interfaces, let me know in the comments!

The When and Why: An Introduction

Welcome to the first post in my When and Why series!

Its my opinion that when learning to code there's a huge emphasis in the resources available on the how of programming. They'll start by describing general ideas that you'll be tackling, then they'll list out and describe syntax you'll be using and what that syntax means to .NET and then they usually end with a small working example demonstrating the functionality of the syntax. To my mind, knowing syntax on its own is a lot like knowing words without understanding good grammar. Programming is as much theoretical as it is practical and taking fifteen minutes to understand the contextual implications of the syntax you've just learned will, inevitably, save you hours and even days in the future because you won't spend all that time trying to use the right tool for the wrong job.

As you probably have already guessed, my When and Why series is an attempt to start filling that void. In each W&W post I'll start with a link to a how resource and then I'll go into explaining when we use that feature and also why we chose to use that feature for those scenarios.

And remember, as with all things programming, the When and Why are not meant as absolutes, they are meant as a guide until you feel confident enough to decide for yourself what the most appropriate tool for a job is.