Top 14 C# Design Patterns Interview Questions and Answers

You can implement thread safe singleton design pattern using the concept of lock in C# as below.

    public class Singleton
    {
        private static object _myLock = new object();
        private static Singleton _singleton = null;

        private Singleton() { }

        public static Singleton Instance()
        {
            if (_singleton is null) // The first check
            {
                lock (_myLock)
                {
                    if (_singleton is null) // The second (double) check
                    {
                        _singleton = new Singleton();
                    }
                }
            }

            return _singleton;
        }
    }

You can also use Lazy class to create a singleton design pattern in C# 4.0 or later, internally it uses double-checked locking by default.

    public class Singleton
    {
        private static readonly Lazy _singleton = new Lazy(() => new Singleton());
        private Singleton() { }
        public static Singleton Instance => _singleton.Value;
    }

Static Class: A static class is a class that lacks the capability of being instantiated, meaning it cannot be used to create objects or instances of itself. It contains only static members (properties, methods, and fields). Static classes are primarily used for utility or helper methods that can be called without creating an instance of the class.

Usage: Static classes are useful when you want to group related utility methods together, and you don't need to maintain any state or instance data. They are often used for mathematical operations, string manipulation, or other utility functions that don't require any object-specific data.

public static class MathUtility
{
    public static double CalculateAreaOfCircle(double radius)
    {
        return Math.PI * radius * radius;
    }

    public static double CalculateAreaOfRectange(double len, double bre)
    {
        return len * bre;
    }
}

In this example, MathUtility is a static class that provides methods for calculating the area of a circle and a triangle. These methods can be called directly without creating an instance of the class, like MathUtility.CalculateCircleArea(5.0).

Singleton Design Pattern: The singleton pattern is a creational design pattern that ensures a class has only one instance and provides a global point of access to it. This pattern is useful when you need to control the number of instances of a class and provide a global access point to that instance.

Usage: Singletons are commonly used in scenarios where you need to manage a shared resource, such as a database connection, a configuration manager, or a logging service. They are also useful when you need to coordinate actions across multiple parts of an application, such as a state management system or a caching mechanism.

public sealed class Logger
{
    private static readonly Logger instance = new Logger();

    private Logger()
    {
        // Constructor is marked as private to prevent any external code from creating instances of the ApplicationLogger class directly.
    }

    public static Logger Instance
    {
        get
        {
            return instance;
        }
    }

    public void Log(string message)
    {
        // Log the message
        Console.WriteLine(message);
    }
}

In this example, Logger is a singleton class. The class employs a private constructor to restrict direct instantiation from outside its scope. Instead, it provides a public static Instance property that acts as the sole gateway to access the instance of the ApplicationLogger class. This property returns the unique instance, ensuring that only one instance of the class exists throughout the application's lifetime. To use the Logger class, you would call Logger.Instance.Log("Some message").
Differences:

• Instantiation: Static classes cannot be instantiated, while singleton classes can be instantiated once and provide a global access point to that instance.
• State Management: Static classes do not maintain any state or instance data, while singletons can maintain state and instance data across multiple parts of the application.
• Inheritance: Static classes cannot be inherited, while singleton classes can be inherited, although it is generally not recommended to derive from singleton classes.
• Thread Safety: Singleton implementation needs to be thread-safe if the application is multi-threaded, while static classes are inherently thread-safe.
• Initialization: Static classes are initialized when the application starts or when their members are first accessed (depending on the .NET version), while singletons are typically lazily initialized or eagerly initialized based on the implementation.

In summary, static classes are used for utility or helper methods that don't require any instance data, while singletons are used to manage a shared resource or coordinate actions across multiple parts of an application.

• The Factory pattern provides an interface for creating objects in a super-class, but allows subclasses to decide which class to instantiate.
• Use cases: Creating objects without exposing the creation logic, creating objects based on configuration or runtime conditions.

Example: Let's say you have a Document interface and concrete implementations like PDFDocument and WordDocument. You can use the Factory Method pattern to create these documents:

public interface IDocument
{
    void Open();
    void Save();
}

public class PDFDocument : IDocument
{
    public void Open() { /* Open PDF logic */ }
    public void Save() { /* Save PDF logic */ }
}

public class WordDocument : IDocument
{
    public void Open() { /* Open Word document logic */ }
    public void Save() { /* Save Word document logic */ }
}

public static class DocumentFactory
{
    public static IDocument CreateDocument(string type)
    {
        switch (type.ToLower())
        {
            case "pdf":
                return new PDFDocument();
            case "word":
                return new WordDocument();
            default:
                throw new ArgumentException("Invalid document type");
        }
    }
}
// You can now create documents like this: 
IDocument doc = DocumentFactory.CreateDocument("pdf");
    

Pros:

• Decouples the object creation code from the client code that uses the objects.
• Allows for the introduction of new object types without modifying existing client code.
• Follows the Open/Closed principle (open for extension, closed for modification).

Cons:

• Can introduce unnecessary complexity for simple scenarios.
• Requires additional classes and interfaces for object creation.
• Can make the code harder to understand and navigate if overused.

• Defines a one-to-many relationship between objects, where changes in one object (the subject) are automatically propagated to its dependents (observers).
• Use cases: Event handling systems, UI controls, stock market updates, etc.

Example: Imagine you have a StockTracker class that notifies its observers (e.g., StockInvestor) when the stock price changes:

public interface IStockObserver
{
    void Update(decimal price);
}

public class StockInvestor : IStockObserver
{
    private string _name;
    public StockInvestor(string name)
    {
        _name = name;
    }

    public void Update(decimal price)
    {
        Console.WriteLine($"{_name} received update: Stock price is {price}");
    }
}

public class StockTracker
{
    private List _observers = new List();
    private decimal _price;

    public void Attach(IStockObserver observer)
    {
        _observers.Add(observer);
    }

    public void Detach(IStockObserver observer)
    {
        _observers.Remove(observer);
    }

    public void UpdatePrice(decimal price)
    {
        _price = price;
        Notify();
    }

    private void Notify()
    {
        foreach (var observer in _observers)
            observer.Update(_price);
    }
}

// You can use it like this
var tracker = new StockTracker();
var investor1 = new StockInvestor("John");
var investor2 = new StockInvestor("Jane");

tracker.Attach(investor1);
tracker.Attach(investor2);

tracker.UpdatePrice(100.5m); // Both investors will be notified
    

Pros:

• With the Observer pattern, the subject and its observers are loosely coupled, meaning they can operate independently and interact without being tightly bound to each other.
• Supports the open/closed principle by allowing new observers to be added without modifying the subject.
• Facilitates event-driven programming and reusability of subjects and observers.

Cons:

• Can lead to memory leaks if observers are not properly unsubscribed or cleaned up.
• Can introduce complexity and make the code harder to debug if there are many observers or complex update logic.
• Observers may be notified unnecessarily, even if they are not interested in the specific change.

• The Decorator pattern allows you to dynamically add responsibilities or behaviors to an object at runtime by wrapping it with another object. It provides an alternative to subclassing for extending functionality.
• Use Case: Adding additional functionality or behavior to an existing file stream, such as compression, encryption, or logging.

public interface IStream
{
    void Write(string data);
}

public class FileStream : IStream
{
    private readonly string filePath;

    public FileStream(string filePath)
    {
        this.filePath = filePath;
    }

    public void Write(string data)
    {
        Console.WriteLine($"Writing data to file: {filePath}");
        Console.WriteLine(data);
        // Actual file writing logic
    }
}

public abstract class StreamDecorator : IStream
{
    protected IStream stream;

    public StreamDecorator(IStream stream)
    {
        this.stream = stream;
    }

    public virtual void Write(string data)
    {
        stream.Write(data);
    }
}

public class CompressionDecorator : StreamDecorator
{
    public CompressionDecorator(IStream stream) : base(stream) { }

    public override void Write(string data)
    {
        // Compress data
        string compressedData = CompressData(data);
        base.Write(compressedData);
    }

    private string CompressData(string data)
    {
        // Compression logic
        return "Compressed: " + data;
    }
}

// calling client
// Create a basic file stream
IStream fileStream = new FileStream("example.txt");

// Decorate the stream with compression
IStream compressedStream = new CompressionDecorator(fileStream);

// Write data to the compressed stream
compressedStream.Write("Hello, World!");
    

Pros:

• Follows the Open/Closed Principle by allowing the addition of new behaviors without modifying existing code.
• Promotes code reusability and flexibility by composing decorators dynamically.
• Avoids the need for creating multiple subclasses or using complex inheritance hierarchies.

Cons:

• Can lead to a large number of small classes, which can make the code harder to understand and maintain.
• Decorators may introduce additional overhead and performance issues if not used carefully.