Can I forbid method to cache passed argument?

Question

Is there a way to prevent method from storing passed argument? I stumbled across this question while considering object pooling.

Let's consider given situation:

public class MyClass
{
    private BigObject myBigObject;

    public MyClass()
    {
        myBigObject = BigObjectsPool.Borrow();
        //initialize myBigObject with some data
    }

    public void ActUpon(ClientClass clientClassInstance)
    {
        clientClassInstance.DoStuff(myBigObject);
    }

    public void Terminate() //MyClass object is no longer needed
    {
        BigObjectsPool.Return(myBigObject);
    }
}

public abstract class ClientClass
{
    public abstract void DoStuff(BigObject bigObject);
}

public class PotentiallyDangerousClientClass : ClientClass
{
    private BigObject cachedBigObject;
    private string cachedString

    public override void DoStuff(BigObject bigObject)
    {
        cachedString = bigObject.SomeString; //this is ok
        cachedBigObject = bigObject; //this will cause problems
    }
}

As you can see, storing bigObject in DoStuff method is dangerous, because in future another instance of MyClass can borrow the same BigObject instance and change it without PotentiallyDangerousClientClass knowledge. Is there a way to ensure safety when passing pooled objects as arguments?

Obvious soultion would be to never expose pooled object and use it only for internal class logic, or expose only it's immutable fields, but it heavily reduces pooling usefulness. Exposing copy of BigObject would render whole pooling obsolete, because I would no longer benefit from reduced allocation.

Answer 1

You can create a thin wrapper around the object that exposes it's members, but only until you release it:

public class TempBigObject : IDisposable
{
    private BigObject bigObject;
    public TempBigObject(BigObject bigObject)
    {
        this.bigObject = bigObject;
    }

    public string SomeString => bigObject.SomeString;

    public void Dispose()
    {
        bigObject = null;
    }
}

If you want to, you can change all of the members, such as SomeString, to throw some more meaningful exception (such as an object disposed exception) when used after disposal, rather than letting null reference exceptions happen.

You can then change ActUpon to something like:

public void ActUpon(ClientClass clientClassInstance)
{
    using TempBigObject temp = new TempBigObject(myBigObject);
    clientClassInstance.DoStuff(temp);
}

This would of course require the clients to use the wrapper type and not the actual type.

Answer 2

Pooling is a performance optimization. And as most optimizations it has an impact on the readability and maintainability of the code. It is up to you to ensure that all references have been released once you return the object to the pool. You are voluntary accepting this responsibility in pursuit of better performance.

You should probably try to limit the scope where BigObject is used. The fewer classes that are involved the less the chance for mistakes and failures are. In some cases it might be useful to create a wrapper for BigObject what can check if the wrapped object have been returned or not, and can throw an error if someone tries to use it after it has been returned.

Of course, you do not have to use pooling. In some cases regular memory allocation is fast enough, and will be safer. There are also some options that can be used to prevent or mitigate the effects of arguments being copied but are not relevant when using an object pool. A ref struct can prevent the type from being used as a field of a non ref struct. Immutable objects are inherently safe to copy (Immutable in the most strict sense, i.e. "deep immutability").