Object Instantiation in C#. Part V Just Don't Do It

Part V. Avoiding It. 

In Part I of this two-part article, we talked about basic instantiation and different way constructors can work.  In Part II we looked at using factory methods.  In Part III we looked at abstract factories.  In Part IV we took a brief look at the builder pattern  and in this final article in the series, we'll be looking at how avoid instantiation altogether.

The Initializer.

There may be situations where we are writing libraries and need to be sure we are not vulnerable to attack.  If we expose instantiation to the consumer of our library they can keep instantiating new objects until we run out of memory.  The way to avoid this is to just not allow instantiation at all.  In order to do this, we'll just consume interfaces with setters on them.

If we define an interface with settable attributes:

interface IGetterSetter
{
    string Prop1 { get; set; }
    string Prop2 { get; set; }
}

we can then create a class for initializing an object that consumes this interface instead of having a factory or a builder:

internal class PropertySetterBase
{
    public PropertySetterBase() { }

    public virtual void Initialize(IGetterSetter target)
    {
        target.Prop1 = string.Empty;
        target.Prop2 = string.Empty;
    }
}

The cool thing is that we don't deal with any kind of memory allocation at all because we are not instantiating any objects at all.  Because we are not allowing the consumer of this library to allocate memory we have a bit more control over what's happening.

On the consumer's side, they would "new-up" a class implementing our interface and use the initializer object to initialize the state.

public class GetterSetter : IGetterSetter
{
    private string
        m_prop1,
        m_prop2;

    public string Prop1
    {
        get { return m_prop1; }
        set { m_prop1 = value; }
    }

    public string Prop2
    {
        get { return m_prop2; }
        set { m_prop2 = value; }
    }
}

And the consumer of our library would initialize their object by passing it to our initializer.  If we implement the initializer as a proveder pattern (a static class exposing the functionality of a base class through a common interface or base object) we will have no points where the user of our library will be able to instantiate objects:

Here is an specific implementation of our property setter:

internal class PropertySetter: PropertySetterBase
{
    public PropertySetter()
   {
        m_prop1val = "Default Value 1";
        m_prop2val = "Default Value 2";
    }

    private string
        m_prop2val,
        m_prop1val;

    public string Prop1val
    {
        get { return m_prop1val; }
        set { m_prop1val = value; }
    }

    public string Prop2val
    {
        get { return m_prop2val; }
        set { m_prop2val = value; }
    }

    public override void Initialize(IGetterSetter target)
    {
        target.Prop1 = m_prop1val;
        target.Prop2 = m_prop2val;
    }
}

And here is our initialization provider:

public static class InitializationProvider
{
    private static PropertySetterBase m_base = new PropertySetter();

    public static void Initialize(IGetterSetter target)
    {
        m_base.Initialize(target);
    }
}

So now, we have effectively avoided instantiation by providing an interface for initialization and a provider to initialize the instance of the object so the user of our class library will instantiate their classes normally and pass them to the InitializationProvider for initialization:

// this instantiation would be performed in the consuming assembly
// and we would just get passed a reference in the InitializationProvider.Initialize() method
GetterSetter objSix = new GetterSetter();
InitializationProvider.Initialize(objSix);

Well, that's about it for object instantiation.  I hope you found this series of articles informative.

Until next time,
Happy coding