Interfaces + Classes + Arguments... should be a simple question... i hope

[Grofit]

Hey there,

Was having a discussion with a co-worker earlier about interfaces and classes, and was just wondering how this would work out behind the scenes...

Imagine you have an interface, lets say called IData, and a class that implements that called Data, then a function somewhere that takes an IData argument and reads it.

Now here is an example of the interface:

public interface IData
{
   int A{get;set;}
   int B{get;set;}
}

Here is an example of the class:

public class Data : IData
{
    private int m_A, m_B, m_C, m_D;
    private somecomplexobject g,h,j,k;

    public int A { get { return m_A;} set { m_A = value; } }
    public int B { get { return m_B;} set { m_B = value; } }

    // Some other complex methods
}

Now here is the function:

void getIData(IData Instance)
{
    Console.WriteLine(Instance.A);
    Console.WriteLine(Instance.B);
}

Now... basically the debate we were having was related to how the function would handle the argument. Would it basically copy the entire object in and just expose the IData parts of the object, or would it just take the IData exposed properties and ignore the rest?

Basically we were wondering from a performance point of view if you had LOADS of massive classes, but only a small fraction of them were needed for most functions, would it make sense to just expose the parts you need via implemented interfaces and just pass the objects over via their interfaces.

Im not sure how the underlying CLR deals with all this...

Anyway if no one knows what im on about no worries, if anyone does know then feel free to shoot any advice or comments over!

[RaleTheBlade]

Im guessing the IData object your passing to that function is really a Data object behind the scenes (no other way to do it really ) so in order to maintain the integrity of the memory, a reference to that object is passed to the function, not the entire object itself.

So if you pass that IData (Data) object to the function and call Instance.A = 24, then when the function call ends and you return control to the caller, the object that you passed to the function will in fact have its A property set to 24 since all classes in the .NET Framework are passed by reference, while structures (structs) are passed by value.

So I guess to sum it up, since the Data object implements the IData interface, you can down-cast it to IData but it will all still work the same on the inside as if it were a Data object instance. You will just only be able to use those members exposed by the IData interface, thats all. The inner members of the Data class will still be there and functional.

Since classes are passed by reference in C#, there is not much overhead involved when simply passing a pointer.

structures - stored on the stack, value on the stack, non-pointer type
classes - stored on the heap, value on the heap, pointer to heap object stored on the stack

So really, when you pass your class like your doing in your example, in the guts of the CLR your just passing a pointer to that object and thats all.

[BigEd781]

Im guessing the IData object your passing to that function is really a Data object behind the scenes (no other way to do it really ) so in order to maintain the integrity of the memory, a reference to that object is passed to the function, not the entire object itself.

So if you pass that IData (Data) object to the function and call Instance.A = 24, then when the function call ends and you return control to the caller, the object that you passed to the function will in fact have its A property set to 24 since all classes in the .NET Framework are passed by reference, while structures (structs) are passed by value.

So I guess to sum it up, since the Data object implements the IData interface, you can down-cast it to IData but it will all still work the same on the inside as if it were a Data object instance. You will just only be able to use those members exposed by the IData interface, thats all. The inner members of the Data class will still be there and functional.

Since classes are passed by reference in C#, there is not much overhead involved when simply passing a pointer.

structures - stored on the stack, value on the stack, non-pointer type
classes - stored on the heap, value on the heap, pointer to heap object stored on the stack

So really, when you pass your class like your doing in your example, in the guts of the CLR your just passing a pointer to that object and thats all.

Just to clear up one thing...

Nothing is passed by reference unless you use the "ref" keyword. The reference is passed by value. I only nitpick here because it is one of the most misunderstood concepts in C# (and some other languages). This means that you can change the state of an object passed to a function by reference, but you cannot change the reference itself unless you use the 'ref' keyword. An example:

void Main
{
    Object obj = new Object();
    Foo(obj);
    // 'obj' is NOT null
}

static void Foo(object o)
{
    o = null;
}

On the other hand...

void Main
{
    Object obj = new Object();
    Foo(ref obj);
    // 'obj' IS null
}

static void Foo(ref object o)
{
    o = null;
}

[RaleTheBlade]

Just to clear up one thing...

Nothing is passed by reference unless you use the "ref" keyword. The reference is passed by value. I only nitpick here because it is one of the most misunderstood concepts in C# (and some other languages). This means that you can change the state of an object passed to a function by reference, but you cannot change the reference itself unless you use the 'ref' keyword. An example:

void Main
{
    Object obj = new Object();
    Foo(obj);
    // 'obj' is NOT null
}

static void Foo(object o)
{
    o = null;
}

On the other hand...

void Main
{
    Object obj = new Object();
    Foo(ref obj);
    // 'obj' IS null
}

static void Foo(ref object o)
{
    o = null;
}

Good call, I totally forgot about the ref keyword