Mastering Creational Design Patterns in .NET: Optimizing Object Creation for Flexibility and Efficiency

Posted by:

Rob Hutton

|

On:

|

, , , , , , , , , , , ,
, , , , , , , ,

In software development, object creation is a fundamental process that significantly impacts application performance, scalability, and maintainability. Creational design patterns provide structured solutions to manage object instantiation efficiently. These patterns ensure flexibility, reduce dependencies, and promote best practices in software design.

This article delves into five essential creational patterns in .NET with practical .NET examples and a breakdown of their implementation:

  1. Singleton — Ensures a single instance of a class. This prevents unnecessary instantiations, saves memory, and ensures consistency across an application.
  2. Factory Method — Provides a mechanism to create objects without exposing instantiation logic. This allows subclasses or configurations to determine the object type at runtime, improving maintainability and scalability.
  3. Abstract Factory — Creates families of related objects. This ensures that the client can work with a set of related objects, making the system more flexible and allowing it to switch between different families of objects without altering the code that uses them.
  4. Builder — Constructs complex objects step by step. This pattern helps manage complexity by separating the construction logic from the object’s representation, making it easier to create and maintain complex objects.
  5. Prototype — Creates new objects by cloning existing ones. This is useful when object creation is resource-intensive, as it enables faster object creation by copying and modifying an existing prototype.

Singleton Pattern

The Singleton Pattern ensures that a class has only one instance, providing a global point of access and efficiently managing shared resources. This not only saves memory but also guarantees consistency throughout the application.

SOLID Principles Supported by the Singleton Pattern

The Singleton pattern is most closely related to the Single Responsibility Principle (SRP) and the Dependency Inversion Principle (DIP) from the SOLID principles:

  1. Single Responsibility Principle (SRP) — The Singleton ensures that only one instance of a class exists, enforcing a single, well-defined responsibility. However, if a Singleton starts managing too many things, it can violate SRP.
  2. Dependency Inversion Principle (DIP) — The Singleton is often used to provide a globally accessible instance, which can lead to tight coupling. However, if accessed through an abstraction (like an interface), it aligns with DIP by ensuring high-level modules depend on abstractions rather than concrete implementations.

Common Use Cases

  • Logging: Ensures all log entries are written to a single location (e.g., file, database), maintaining consistency across the application.
  • Caching: Provides a centralized store for cached data, preventing redundant retrieval and improving performance.
  • Database Connections: Reduces overhead by maintaining a single shared connection, improving efficiency and resource management.
  • Configuration Management: Ensures consistent access to application settings by maintaining a single source of truth throughout the app’s lifecycle.

Implementing the Singleton Pattern to Manage Database Context

You are building an application where business logic needs to interact with a SQL database (using Entity Framework) to query product information. We’ll use the Singleton pattern to manage the database context, ensuring only one instance of the database context is created and shared throughout the application. This improves performance and prevents issues like exceeding the maximum allowed connections.

1️⃣ Define the Entity Framework Model

First, define an entity model that represents a table in the database. This model will be used by Entity Framework to interact with the database.

This Product class maps to a table in the database, where each property corresponds to a column.

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

2️⃣ Create the Database Context (with EF Core)

The ApplicationDbContext class is responsible for managing interactions with the database. It extends DbContext, which provides functionality for querying and saving data.

This class defines the Products table and will be used throughout the application to interact with the database.

public class ApplicationDbContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { }
}

3️⃣ Create the Singleton Service for Database Operations

Create a service that follows the Singleton pattern to manage database interactions. The goal is to ensure a single instance of ApplicationDbContext is used, avoiding unnecessary overhead.

  • The DatabaseService class ensures that only one instance of ApplicationDbContext is created.
  • The GetInstance method checks if the context already exists. If not, it retrieves it from the DI container.
  • A lock is used to make it thread-safe, ensuring multiple threads do not create duplicate instances.
  • The private constructor prevents direct instantiation, enforcing the Singleton pattern.
public interface IDatabaseService
{
    Task<IEnumerable<Product>> GetAllProductsAsync();
}

public class DatabaseService : IDatabaseService
{
    private static ApplicationDbContext _context;
    private static readonly object Lock = new object();

    // Private constructor to prevent instantiation
    private DatabaseService() {}

    // Public method to get the single instance of the database context
    public static IDatabaseService GetInstance(IServiceProvider serviceProvider)
    {
        if (_context == null)
        {
            lock (Lock)
            {
                if (_context == null)
                {
                    _context = serviceProvider.GetRequiredService<ApplicationDbContext>();
                }
            }
        }

        return new DatabaseService(_context);
    }

    // Use this instance to access the database
    private readonly ApplicationDbContext _dbContext;

    private DatabaseService(ApplicationDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task<IEnumerable<Product>> GetAllProductsAsync()
    {
        return await _dbContext.Products.ToListAsync();
    }
}

4️⃣ Register Singleton in Dependency Injection (DI)

Now, register the DatabaseService as a Singleton in the DI container. This ensures that the same instance is used throughout the application.

  • AddDbContext registers ApplicationDbContext, allowing it to be injected.
  • AddSingleton ensures only one instance of DatabaseService is created and used.
public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer("YourConnectionString")); // configure EF with your DB

    services.AddSingleton<IDatabaseService>(sp => DatabaseService.GetInstance(sp));
}

5️⃣ Use the Singleton Database Service in a Business Logic Class or Controller

Use the DatabaseService to fetch product data in a service layer or controller.

  • ProductService depends on IDatabaseService, allowing for better separation of concerns.
  • The Singleton pattern ensures efficient, consistent database access across the application.
public class ProductService
{
    private readonly IDatabaseService _databaseService;

    public ProductService(IDatabaseService databaseService)
    {
        _databaseService = databaseService;
    }

    public async Task<IEnumerable<Product>> GetProductsAsync()
    {
        return await _databaseService.GetAllProductsAsync();
    }
}

Factory Method Pattern

The Factory Method pattern provides an interface for creating objects, but lets subclasses determine which class to instantiate. It’s particularly useful for promoting loose coupling in your application and encapsulating object creation logic. This pattern is especially beneficial when the exact type of object to be created is determined at runtime, depending on the context or configuration. By using the Factory Method, you can avoid direct instantiation and enable more flexible and maintainable code that can evolve with changing requirements.

SOLID Principles Supported by the Factory Pattern

The Factory Pattern primarily adheres to the following SOLID principles:

  1. Open/Closed Principle (OCP) — The Factory Pattern allows new product types (new concrete classes) to be introduced without modifying existing code. This makes the system more extensible and avoids direct modifications to client code when adding new implementations.
  2. Dependency Inversion Principle (DIP) — The Factory Pattern ensures that high-level modules depend on abstractions, not concrete implementations. Instead of instantiating objects directly (which creates tight coupling), the factory returns an instance of an abstract type (interface or base class), promoting flexibility and maintainability.

Common Use Cases

  • Database Connections: The Factory Pattern abstracts database connection creation, allowing seamless switching between SQL, NoSQL, or mock databases without modifying client code.
  • Logging Frameworks: It enables dynamic logger selection (Console, File, Database) based on environment needs, keeping the application decoupled from specific logging implementations.
  • Dependency Injection: Factories help DI frameworks instantiate classes with required dependencies, enhancing flexibility and making it easy to swap implementations (e.g., local cache vs. cloud service).

Implementing the Factory Pattern for Payment Processing

The Factory Pattern allows us to instantiate different payment processors dynamically, ensuring flexibility and decoupling payment logic from the application. This makes it easy to switch between payment methods (Credit Card, PayPal, Bank Transfer) without modifying business logic.

This implementation makes it easy to switch payment methods or add new ones without modifying existing business logic, keeping the code clean, scalable, and maintainable.

1️⃣ Define the Payment Processor Interface

We start by defining a common contract that all payment processors must follow.

The code creates an interface, IPaymentProcessor, which declares a ProcessPayment() method that each concrete payment processor will implement.

public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

2️⃣ Implement Concrete Payment Processors

We create specific payment processor classes, each handling a different payment method (e.g., Credit Card, PayPal).

These classes implement the IPaymentProcessor interface and provide their own logic inside the ProcessPayment() method.

public class CreditCardPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment of {amount:C}");
    }
}

public class PayPalPaymentProcessor : IPaymentProcessor
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing PayPal payment of {amount:C}");
    }
}

3️⃣ Create the Factory Interface

To ensure that payment processors are created dynamically, we define a factory class.

The abstract class PaymentProcessorFactory declares an abstract method, CreateProcessor(), which will be implemented by concrete factories.

public abstract class PaymentProcessorFactory
{
    public abstract IPaymentProcessor CreateProcessor();
}

4️⃣ Implement Concrete Factories

Each payment method gets its own factory class that knows how to create the correct payment processor. These concrete factory classes override CreateProcessor() to return the appropriate implementation of IPaymentProcessor.

public class CreditCardProcessorFactory : PaymentProcessorFactory
{
    public override IPaymentProcessor CreateProcessor()
    {
        return new CreditCardPaymentProcessor();
    }
}

public class PayPalProcessorFactory : PaymentProcessorFactory
{
    public override IPaymentProcessor CreateProcessor()
    {
        return new PayPalPaymentProcessor();
    }
}

5️⃣ Use the Factory in the Application

To keep payment processing flexible, we use the factory pattern to instantiate the appropriate payment processor at runtime.

The PaymentService class receives a PaymentProcessorFactory in its constructor, uses it to create a processor, and delegates payment processing to that processor.

public class PaymentService
{
    private readonly IPaymentProcessor _processor;

    public PaymentService(PaymentProcessorFactory factory)
    {
        _processor = factory.CreateProcessor();
    }

    public void ProcessPayment(decimal amount)
    {
        _processor.ProcessPayment(amount);
    }
}

6️⃣ Configure and Execute

Finally, we create an instance of the appropriate factory and use it to process a payment.

The Main() method selects a factory (e.g., PayPalProcessorFactory), instantiates the PaymentService, and initiates payment processing.

class Program
{
    static void Main()
    {
        PaymentProcessorFactory factory = new PayPalProcessorFactory(); // Change dynamically as needed
        var paymentService = new PaymentService(factory);
        paymentService.ProcessPayment(100.00m);
    }
}

Abstract Factory Pattern

The Abstract Factory Pattern is an extension of the Factory Method pattern, offering an interface for creating families of related or dependent objects without specifying concrete classes. It allows you to create sets of related objects that can be used together, without the client code knowing about the specifics of the object creation. This is especially useful in scenarios where multiple families of products need to be created, each family containing a set of related objects. The pattern enables high flexibility, as it allows you to switch between these families easily, without changing the core logic of the application.

SOLID Principles Supported by the Abstract Factory Pattern

Open/Closed Principle: This SOLID principle states that a class should be open for extension but closed for modification. The Abstract Factory Pattern supports this principle by allowing you to add new types of products (e.g., new UI components for a different platform) without modifying the existing client code or factory classes. Instead, you can extend the existing design with new concrete factories and product implementations.

Common Use Cases

  • UI Component Libraries — Ensures consistency by providing a unified way to create platform-specific UI components (e.g., buttons, text fields) without tightly coupling the application to a specific implementation. This simplifies maintenance and promotes scalability.
  • Cross-Platform Development — Enables platform-agnostic code by abstracting platform-specific components (e.g., iOS vs. Android). This ensures that the correct version is instantiated without exposing platform details to the application, improving flexibility and code reuse.
  • Theming Systems — Facilitates seamless theme switching by dynamically generating UI components that conform to a selected theme (e.g., dark mode, light mode). This keeps the UI consistent while keeping the logic for theme variations centralized and easy to manage.

Implementing the Abstract Factory Pattern in a Cross-Platform UI

You’re building a cross-platform UI that supports both web and desktop applications. Each platform has a distinct design style — web UI uses flat design, while desktop UI has more traditional, 3D-styled components.

We need a scalable solution where UI components remain interchangeable while ensuring platform-specific designs without modifying existing code.

The Abstract Factory Pattern helps us achieve this by defining a family of related objects (UI components) without specifying their concrete classes, ensuring a clean separation between platform-specific logic and shared application code.

1️⃣ Define the Abstract Product Interfaces

We are defining a set of common blueprints for the UI components, ensuring they have the same behavior across different platforms.

This step involves creating interfaces for IButton, ITextField, and INavigationBar that declare the Render() method that must be implemented by all platform-specific components.

public interface IButton
{
    void Render();
}

public interface ITextField
{
    void Render();
}

public interface INavigationBar
{
    void Render();
}

2️⃣ Create Web-Specific UI Components

In this step, we create the specific components for the web version of the app, ensuring they follow the flat design style.

The WebButton, WebTextField, and WebNavigationBar classes implement the interfaces defined earlier, with each class rendering components that reflect the web’s flat design.

public class WebButton : IButton
{
    public void Render()
    {
        Console.WriteLine("Rendering Web Button with Flat Design");
    }
}

public class WebTextField : ITextField
{
    public void Render()
    {
        Console.WriteLine("Rendering Web Text Field with Flat Design");
    }
}

public class WebNavigationBar : INavigationBar
{
    public void Render()
    {
        Console.WriteLine("Rendering Web Navigation Bar with Flat Design");
    }
}

3️⃣ Create Concrete Products for Desktop Platform

In this step, we define the components for the desktop version of the app, adhering to a more traditional 3D design style.

The DesktopButton, DesktopTextField, and DesktopNavigationBar implement the same interfaces but render with a 3D style suitable for desktop applications.

public class DesktopButton : IButton
{
    public void Render()
    {
        Console.WriteLine("Rendering Desktop Button with 3D Design");
    }
}

public class DesktopTextField : ITextField
{
    public void Render()
    {
        Console.WriteLine("Rendering Desktop Text Field with 3D Design");
    }
}

public class DesktopNavigationBar : INavigationBar
{
    public void Render()
    {
        Console.WriteLine("Rendering Desktop Navigation Bar with 3D Design");
    }
}

4️⃣ Define the Abstract Factory Interface

We are creating an interface that dictates how to build the UI components, without worrying about which platform they belong to.

The IUIComponentFactory interface defines methods for creating a button, text field, and navigation bar, which will be implemented by platform-specific factories.

public interface IUIComponentFactory
{
    IButton CreateButton();
    ITextField CreateTextField();
    INavigationBar CreateNavigationBar();
}

5️⃣ Implement Concrete Factories for Each Platform

This step implements the concrete factories that are responsible for creating platform-specific components.

The WebUIComponentFactory and DesktopUIComponentFactory return the appropriate concrete classes for the web and desktop platforms, respectively.

public class WebUIComponentFactory : IUIComponentFactory
{
    public IButton CreateButton()
    {
        return new WebButton();
    }

    public ITextField CreateTextField()
    {
        return new WebTextField();
    }

    public INavigationBar CreateNavigationBar()
    {
        return new WebNavigationBar();
    }
}

public class DesktopUIComponentFactory : IUIComponentFactory
{
    public IButton CreateButton()
    {
        return new DesktopButton();
    }

    public ITextField CreateTextField()
    {
        return new DesktopTextField();
    }

    public INavigationBar CreateNavigationBar()
    {
        return new DesktopNavigationBar();
    }
}

6️⃣ Client Code Using Abstract Factory

In this step, we set up the client code to use the abstract factory.

The UIClient class takes an IUIComponentFactory as a dependency, creating the appropriate UI components (button, text field, and navigation bar) and calling their Render() method.

public class UIClient
{
    private readonly IButton _button;
    private readonly ITextField _textField;
    private readonly INavigationBar _navigationBar;

    public UIClient(IUIComponentFactory factory)
    {
        _button = factory.CreateButton();
        _textField = factory.CreateTextField();
        _navigationBar = factory.CreateNavigationBar();
    }

    public void RenderUI()
    {
        _button.Render();
        _textField.Render();
        _navigationBar.Render();
    }
}

7️⃣ Use the Factory Based on Platform

Finally, we use the factory pattern to decide which platform-specific factory to use.

Based on the environment (web or desktop), we instantiate the corresponding UIComponentFactory and pass it to the UIClient, which then renders the correct set of components.

public class Program
{
    public static void Main(string[] args)
    {
        IUIComponentFactory uiFactory;

        // Assume we're in a web environment
        uiFactory = new WebUIComponentFactory();

        var client = new UIClient(uiFactory);
        client.RenderUI(); // Outputs: Web-specific UI components

        // Now, assume we're in a desktop environment
        uiFactory = new DesktopUIComponentFactory();

        client = new UIClient(uiFactory);
        client.RenderUI(); // Outputs: Desktop-specific UI components
    }
}

Builder Pattern

The Builder Pattern is a creational design pattern that allows you to construct a complex object step by step, separating the construction process from the actual object. It is particularly useful when an object has many optional parameters, helping to avoid complex constructors and providing a clear, readable way to build objects.

Common Use Cases

  • Creating Immutable Objects: The Builder pattern helps in creating immutable objects with optional fields, ensuring that the object is fully constructed before being used. It provides a clean way to set only the necessary parameters without worrying about missing required ones.
  • Configuring Objects with Multiple Optional Parameters: When an object has many optional parameters, the Builder pattern allows you to set only the required ones while maintaining flexibility. It avoids the complexity of long constructors or setter methods.

SOLID Principles Supported by the Builder Pattern

  • Single Responsibility Principle (SRP): The Builder pattern ensures that the object construction logic is separated from the object’s internal logic, allowing each class to focus on a single responsibility.
  • Open/Closed Principle (OCP): The Builder class can be extended to support new features without modifying existing code. You can add new parameters or methods to the builder without changing the core object.
  • Liskov Substitution Principle (LSP): Builders can be subclassed or extended with minimal changes, allowing different types of builders to be used interchangeably.
  • Interface Segregation Principle (ISP): The Builder pattern promotes the use of multiple builder interfaces, focusing on specific object attributes, which reduces the need for monolithic builder classes.
  • Dependency Inversion Principle (DIP): The builder pattern encourages decoupling between the object construction and the object’s representation, which aligns with high-level modules depending on abstractions.

Implementing the Builder Pattern for Constructing HTTP Requests

In this example, we demonstrate the use of the Builder pattern to construct an HttpRequest object. This pattern is particularly useful when dealing with objects that require multiple optional parameters, like headers, URL, and body content. The Builder pattern helps to keep the object construction process clear, flexible, and readable, and it is commonly used in real-world web development scenarios, such as constructing HTTP requests.

1️⃣ Define the HTTP Request Class

The HttpRequest class holds various attributes related to an HTTP request. These attributes will be set through the builder.

public class HttpRequest
{
    public string Url { get; set; }
    public string Method { get; set; }
    public Dictionary<string, string> Headers { get; set; }
    public string Body { get; set; }

    public HttpRequest(string url, string method, Dictionary<string, string> headers, string body)
    {
        Url = url;
        Method = method;
        Headers = headers;
        Body = body;
    }
}

2️⃣ Create the Builder Class

The builder provides fluent setter methods for each optional property of the HttpRequest. These methods set the value for each attribute and return the builder itself. Finally, the Build() method creates and returns the constructed HttpRequest.

public class HttpRequestBuilder
{
    private string _url;
    private string _method;
    private Dictionary<string, string> _headers = new Dictionary<string, string>();
    private string _body;

    public HttpRequestBuilder SetUrl(string url)
    {
        _url = url;
        return this;
    }

    public HttpRequestBuilder SetMethod(string method)
    {
        _method = method;
        return this;
    }

    public HttpRequestBuilder AddHeader(string key, string value)
    {
        _headers.Add(key, value);
        return this;
    }

    public HttpRequestBuilder SetBody(string body)
    {
        _body = body;
        return this;
    }

    public HttpRequest Build()
    {
        return new HttpRequest(_url, _method, _headers, _body);
    }
}

3️⃣ Construct the HTTP Request Using the Builder

The builder is instantiated, various setter methods are called to define the attributes of the HTTP request, and finally, Build() returns the constructed HttpRequest object.

public class Program
{
    public static void Main(string[] args)
    {
        // Build an HTTP request using the builder
        HttpRequest request = new HttpRequestBuilder()
            .SetUrl("https://api.example.com/data")
            .SetMethod("GET")
            .AddHeader("Authorization", "Bearer token")
            .AddHeader("Accept", "application/json")
            .SetBody("")  // No body for GET request
            .Build();

        Console.WriteLine($"Request: {request.Method} {request.Url}");
        foreach (var header in request.Headers)
        {
            Console.WriteLine($"{header.Key}: {header.Value}");
        }
    }
}

Prototype Pattern

The Prototype Pattern is a creational design pattern that allows you to create new objects by copying an existing object, known as the prototype. This pattern is especially useful when the cost of creating an object from scratch is expensive, and cloning an existing instance is more efficient. By copying prototypes, we can create complex objects with minimal overhead.

Common Use Cases

  • Cloning Complex Objects: The Prototype pattern is beneficial when creating many copies of an object that shares the same structure, and creating these copies from scratch would be resource-intensive.
  • Avoiding Object Construction Overhead: In scenarios where object creation is expensive or slow, cloning an object via the Prototype pattern can save time and system resources by avoiding the need to re-create similar objects.

SOLID Principles Supported by the Prototype Pattern

  • Single Responsibility Principle (SRP): The Prototype pattern separates the logic of creating new instances from the rest of the application, allowing the object creation process to have a single responsibility.
  • Open/Closed Principle (OCP): The Prototype pattern allows new types of objects to be created through cloning without modifying the existing class structure, supporting extensibility without modification.
  • Liskov Substitution Principle (LSP): Cloning objects works well with subclasses, and prototype objects can be swapped without affecting the integrity of the system, ensuring that subclasses can be substituted.
  • Interface Segregation Principle (ISP): By using a shared interface for cloning, the Prototype pattern ensures that objects implement only the necessary cloning logic and don’t inherit unnecessary methods.
  • Dependency Inversion Principle (DIP): The Prototype pattern encourages relying on abstractions (e.g., cloning interface) instead of concrete implementations, making the system easier to extend and modify.

Implementation of the Prototype Pattern to Clone a Configuration Object

In this example, the Prototype pattern is used to create a Configuration object and clone it. The Clone() method allows us to duplicate the object without recreating the configuration from scratch, saving time and resources. This pattern is extremely useful when you need to create multiple copies of an object with the same configuration, such as when handling application settings or user sessions. The Prototype pattern helps keep object creation efficient, especially when the objects are complex and costly to construct.

1️⃣ Define the Prototype Interface

We define a IPrototype interface that includes a method Clone(). This interface will ensure that objects can clone themselves.

public interface IPrototype<T>
{
    T Clone();
}

2️⃣ Create the Concrete Class Implementing the Prototype

Next, we create a Configuration class that implements the IPrototype interface. This class will contain various configuration settings that can be cloned.

public class Configuration : IPrototype<Configuration>
{
    public string SettingA { get; set; }
    public int SettingB { get; set; }

    public Configuration(string settingA, int settingB)
    {
        SettingA = settingA;
        SettingB = settingB;
    }

    // Implement the Clone method
    public Configuration Clone()
    {
        return new Configuration(SettingA, SettingB);
    }
}

3️⃣ Clone the Object Using the Prototype

Finally, we demonstrate how to clone the Configuration object. This is where the Prototype pattern shines by allowing us to easily duplicate the object without the need to reconfigure everything.

public class Program
{
    public static void Main(string[] args)
    {
        // Original configuration
        Configuration originalConfig = new Configuration("High", 10);

        // Clone the original configuration
        Configuration clonedConfig = originalConfig.Clone();

        // Print both configurations
        Console.WriteLine($"Original: {originalConfig.SettingA}, {originalConfig.SettingB}");
        Console.WriteLine($"Cloned: {clonedConfig.SettingA}, {clonedConfig.SettingB}");
    }
}

Creational design patterns are essential for managing object creation efficiently in .NET applications. Each pattern serves a specific purpose:

  • Singleton ensures only one instance of a class exists.
  • Factory Method centralizes the logic of object creation.
  • Abstract Factory provides families of related objects.
  • Builder constructs complex objects step-by-step.
  • Prototype facilitates object cloning.

By understanding these patterns, developers can enhance application maintainability, scalability, and performance. Choosing the right pattern based on the application’s needs allows developers to write cleaner, more modular, and flexible code.

Posted by

Rob Hutton

in

, , , , , , , , , , , ,