Design Patterns in C#

Overview

• The Singleton Pattern
• Dependency Injection

The Singleton Pattern

The problem

• In most cases, it makes no sense to create an instance of a class every time its members need to be accessed
  • For example, a shared resource manager that is being called from multiple classes
• While a static class could be used for this, there are some problems:
  • As stated in lecture 10, static classes can only have static members
  • Static classes cannot be instantiated, so a reference to them cannot be passed around as a parameter
  • Static classes cannot inherit from other classes or implement interfaces
  • And many more...

The solution

• The singleton class is a class that benefits from all the perks of a non-static class (non-static members, inheritance, referencing…), but only one (or zero) instances of it ever exists during the lifetime of your application
• For example, reading from / writing to a file that should be accessible to multiple clients, should be made into a singleton
  • Instead of every client directly accessing the same file (and possibly causing massive performance issues), the singleton is instantiated once and a reference to it is provided to clients
  • The singleton could take care of queueing the read/write requests and be the only entity accessing the actual file

A singleton implementation could look something like this:

class Singleton
{
  private static Singleton instance = null;

  private Singleton() { }
  public void MySingletonFunction()
  {
    Console.WriteLine
      ("This function is accessible anywhere!");
  }

  public static Singleton Instance
  {
    get
    {
      if (instance == null)
        instance = new Singleton();
      return instance;
    }
  }
}

class Program
{
  static void Main(string[] args)
  {
    Singleton.Instance.MySingletonFunction();
    // Outputs: "This function is accessible
    // from everywhere!"
  }
}

Implementing a singleton pattern

• The exact implementation of the singleton is out of the scope of this course, but it is important to understand that it exists and what its purpose is
• Multitude of examples for different use cases are available and can be found by googling

Dependency Injection

The problem

• Traditionally, when new objects of classes are instantiated, the consuming class handles the creation of the objects
• Many classes change their functionality throughout the development of any project
  • This means that also every single consuming class has to change
  • This is called tight coupling

The solution

• What if, instead of directly creating the objects, they were provided by some interface that takes care of the creation?
• This way, even if the base class changes, the consuming classes won't care because they only know about the provider
• This provider is called Container, and the functionality being injected is called Service
• In ASP.NET, this container system is built in

Dependency injection in ASP.NET

public class HomeController : Controller
{
  private readonly IUserRepository _userRepository;

  public HomeController(IUserRepository userRepository)
  {
    _userRepository = userRepository;
  }
  // User repository including all users is now accessible in HomeController
}

Design Patterns

• If the concepts of a singleton and dependency injection flew over your head, don't worry about it

• The important thing is to know they exist so that when they come up again in ASP.NET, you have already familiarized yourself with the terms

  • Thus, understanding the logic behind ASP.NET becomes less overwhelming

• There are many more design patterns, see the material here

  public void ConfigureServices(IServiceCollection services)
  {
    services.AddSingleton<IDateTime, SystemDateTime>();
    services.AddControllersWithViews();
  }