RDRYUSLOG DEV
Back to Blog
C#

C# Private Constructor Usage and Patterns

c# private constructor: Learn when and how to use a private constructor in C#: control instantiation, implement singletons, and support factory methods with practical...

C# constructorsSingleton patternstatic classesfactory methodsaccess modifiers
Diagram illustrating a C# class with a private constructor preventing external instantiation, shown as a lock on the constructor.

A private constructor in C# restricts instantiation of a class to within the class itself. This is not a common default; most classes are designed to be instantiated freely with a public constructor. When you mark a constructor as private, external code cannot call new on that class. This simple access modifier change enables several important design patterns and behavior controls.

The primary use cases for a c# private constructor are: preventing instantiation of a class that only contains static members, implementing the singleton pattern, and providing factory methods that control how instances are created. Understanding these patterns helps you decide when a private constructor is the right tool and when it introduces unnecessary complexity.

Declaring a Private Constructor

Declaring a private constructor is syntactically identical to declaring any other constructor, but the access modifier is private.

public class Logger
{
    private Logger()
    {
        // Initialization code that only the class itself can run
    }

    public static void Log(string message)
    {
        // Static logging logic
    }
}

In this example, the Logger class has no public or internal constructor. External code cannot write new Logger() because the constructor is not accessible. However, the class itself can still create instances internally.

A class with only a private constructor cannot be inherited externally either, because derived classes must call a base constructor, and the base constructor is not accessible. This makes the class effectively non-inheritable unless the private constructor is called from within the same class via a nested derived class.

Preventing Instantiation for Static-Member Classes

If a class contains only static members, such as utility methods or constants, there is no reason to ever instantiate it. All members are accessed through the class name, not an instance.

public class StringUtils
{
    private StringUtils()
    {
        // Prevents instantiation
    }

    public static bool IsNullOrWhitespace(string input)
    {
        return string.IsNullOrWhiteSpace(input);
    }

    public static string Truncate(string value, int maxLength)
    {
        if (string.IsNullOrEmpty(value)) return value;
        return value.Substring(0, Math.Min(value.Length, maxLength));
    }
}

By making the constructor private, you signal to other developers that this class is not meant to be instantiated. Any attempt to create an instance with new StringUtils() fails at compile time with an accessibility error. This prevents accidental object creation, which would be misleading because the instance would have no usable state.

Before C# 2.0, developers would add a private constructor to achieve this. However, modern C# provides static classes for this exact purpose. A static class is declared with the static modifier and cannot be instantiated or inherited.

public static class StringUtils
{
    public static bool IsNullOrWhitespace(string input)
    {
        return string.IsNullOrWhiteSpace(input);
    }
}

A static class is a stronger guarantee: the compiler enforces that all members are static and that the class cannot be instantiated. If you are writing a class that only contains static members, prefer a static class over a private constructor. The private constructor approach is now mainly useful when you need to combine static and instance members but still want to prevent external instantiation.

Implementing the Singleton Pattern

The singleton pattern ensures that a class has exactly one instance and provides a global access point to that instance. A private constructor is essential to the standard implementation because it prevents external code from creating additional instances.

public class ConfigurationManager
{
    private static readonly Lazy<ConfigurationManager> _instance =
        new Lazy<ConfigurationManager>(() => new ConfigurationManager());

    private ConfigurationManager()
    {
        // Load configuration from file or environment
    }

    public static ConfigurationManager Instance => _instance.Value;

    public string GetSetting(string key)
    {
        // Simulated lookup
        return $"Value for {key}";
    }
}

Here the constructor is private, so the only way to get an instance is through the static Instance property. The Lazy<T> type ensures the instance is created only on first access and that the creation is thread-safe by default.

If the constructor were public, any code could create a second ConfigurationManager, breaking the single-instance guarantee. The private constructor enforces the pattern at the language level.

There are variations: some implementations use a static field initialized directly, while others use a double-checked lock. The Lazy<T> approach is concise and safe for most scenarios. If you need more control over initialization timing, you can use a static constructor, which is invoked automatically before the first static member access.

public class DatabaseConnection
{
    private static readonly DatabaseConnection _instance;

    static DatabaseConnection()
    {
        _instance = new DatabaseConnection();
    }

    private DatabaseConnection()
    {
        // Initialize connection pool
    }

    public static DatabaseConnection Instance => _instance;
}

The static constructor runs exactly once per AppDomain. The runtime handles synchronization, so you do not need additional locking.

Using Private Constructors in Factory Methods

Factory methods are static methods that create and return instances of a class. Unlike a constructor, a factory method can return an existing instance, a cached object, or an instance of a derived type. A private constructor ensures that the factory is the only way to create instances, giving you a controlled creation point.

Suppose you have a class that represents a coordinate. You want to ensure that coordinates are always within a valid range. The constructor can validate the inputs, but you might also want to provide a separate method that performs conversion.

public class Coordinate
{
    public double X { get; }
    public double Y { get; }

    private Coordinate(double x, double y)
    {
        X = x;
        Y = y;
    }

    public static Coordinate Create(double x, double y)
    {
        if (double.IsNaN(x) || double.IsNaN(y))
        {
            throw new ArgumentException("Coordinates must not be NaN.");
        }
        return new Coordinate(x, y);
    }

    public static Coordinate FromPolar(double radius, double angle)
    {
        if (radius < 0)
        {
            throw new ArgumentException("Radius cannot be negative.");
        }
        return new Coordinate(radius * Math.Cos(angle), radius * Math.Sin(angle));
    }
}

External code cannot call new Coordinate(1, 2) because the constructor is private. They must use one of the factory methods. This makes the validation and conversion logic the only paths to instance creation. You can change the internal representation without breaking callers, as long as the factory methods remain compatible.

Factory methods also allow you to return instances from a cache or pool, which is not possible with a direct constructor call.

Common Mistakes and Pitfalls

One common mistake is using a private constructor when a static class would be clearer. If all members of the class are static, a static class communicates the intent better and prevents accidental instantiation at compile time. Using a private constructor for a static-only class is not wrong, but it is outdated.

Another mistake is making the constructor private but forgetting to provide a static access point. You end up with a class that can never be instantiated, which is sometimes intentional but often a design flaw. If the class is meant to be used, you need a factory method or a static instance property.

A subtle issue arises with reflection. Even though the constructor is private, reflection can invoke it. This matters in libraries that use reflection to create objects, such as deserializers or IoC containers. If you rely on a private constructor to prevent instantiation entirely, reflection is a loophole. Usually, the goal of a private constructor is to prevent typical code from instantiating the class, not to create a hard security boundary.

Inheritance and private constructors interact in a way that can surprise developers. Because a derived class must call a base constructor, a class with only a private constructor cannot be subclassed except by nested classes within the same class. This effectively seals the class for inheritance. If you need inheritance, do not use a private constructor; use a protected or public constructor instead.

Performance and Thread Safety Considerations

The main performance concern with private constructors is in singleton implementations. Creating an instance lazily adds a small overhead on first access due to the null check and lock inside Lazy<T>. Subsequent accesses are fast field reads. In most applications, this overhead is negligible compared to the cost of creating and managing a true singleton object.

Thread safety is the more important operational concern. If you implement a singleton manually without proper locking, you risk creating multiple instances in a multi-threaded environment. The Lazy<T> approach is thread-safe by default. If you use a static constructor, the runtime guarantees that it runs only once per AppDomain. Manual double-checked locking is more error-prone and rarely necessary.

Factory methods that use a private constructor do not have special performance implications unless they do heavy work such as caching. If you cache instances, you must consider thread safety for the cache itself. For example, using a ConcurrentDictionary for a cache is safer than a plain Dictionary in multi-threaded code.

When to Avoid a Private Constructor

A private constructor is not the right choice for every class where you want to control creation. If you need to support inheritance, use a protected constructor. If you want callers to construct the object but also perform some logic, a public constructor with validation is simpler. A private constructor adds an extra indirection layer through a factory, which may be unnecessary for a simple data class.

Consider a value object like Money. You could make the constructor private and provide a Create method, but the constructor itself is not doing anything beyond assigning fields. Making it public reduces boilerplate:

public class Money
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        Amount = amount;
        Currency = currency ?? throw new ArgumentNullException(nameof(currency));
    }
}

The validation is still centralized. A private constructor would only add noise unless you need to prevent non-factory instantiation for some other reason.

Another case where a private constructor is unnecessary is when you use a library that requires a public parameterless constructor, such as some serialization frameworks or DI containers. A private constructor can break those tools because they cannot create an instance without reflection.

Combining with Other C# Features

The c# private constructor can be combined with other features to produce flexible designs. For example, you can use a readonly field for a constant instance, or you can use an immutable type with a private constructor and a fluent builder.

A builder pattern often uses a private constructor for the product and a separate builder class that has access to the private constructor because it is a nested class.

public class Order
{
    public int Id { get; }
    public string CustomerName { get; }

    private Order(int id, string customerName)
    {
        Id = id;
        CustomerName = customerName;
    }

    public class Builder
    {
        private int _id;
        private string _customerName = string.Empty;

        public Builder WithId(int id)
        {
            _id = id;
            return this;
        }

        public Builder WithCustomerName(string name)
        {
            _customerName = name;
            return this;
        }

        public Order Build()
        {
            return new Order(_id, _customerName);
        }
    }
}

The nested Builder can access the private constructor because in C#, nested types can access private members of the containing type. This gives you a fluent API while keeping the constructor private to enforce that all orders go through the builder, which can enforce invariants.

This pattern is useful for objects that require many optional parameters or require a strict construction sequence.

Final Code Example: Lazy Singleton with Configuration

To tie the concepts together, here is a final example of a configuration provider that uses a c# private constructor, lazy initialization, and a factory method for a default instance.

public class AppConfig
{
    private static readonly Lazy<AppConfig> _lazy = new Lazy<AppConfig>(() => new AppConfig());

    private AppConfig()
    {
        // Load configuration from environment variables or file
    }

    public static AppConfig Instance => _lazy.Value;

    public string GetEnvironment()
    {
        return Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Production";
    }
}

This class cannot be instantiated by external code. The single instance is created when Instance is first accessed, and the lazy initialization is thread-safe. The private constructor ensures we do not accidentally create a second instance. If you later need to support testability, you can add an internal constructor or use a factory, but for a production config access point, this is a clean design.

Choosing a private constructor is about communicating your design intent. It tells future developers that this class is not meant to be freely instantiated and that there is a controlled creation path. Used appropriately, it is a valuable tool in your C# toolbox.

c# private constructor: Practical Usage and Code Examples | RYUSLOG DEV