Mixing object model and interface model.

  • Thread starter Thread starter Steven Quail
  • Start date Start date
S

Steven Quail

Hi to all,

Having come from a delphi environment, I remember that when using
interfaces, we were told not to mix the object models and interface
models. In other words, when I create an object, return and interface
straight away, instead of creating an object of type object and then
getting the interface. The reason given for this was that when passing
interfaces around, the interface could
release the object and then if I try to use the object reference, I
would
get access violations.

In C# I have seen examples like:

Person myPerson;
AddressInterface IAddress;


myPerson = Person.Create;
AddressInterface = myPerson as IAddress;

etc.

Is this correct or should I do :

AddressInterface = Person.Create;

In which case I never ever use myPerson.

TIA
Steven.
 
Steven,

I think the question is moot, because if you are going to use an
interface model, then you should be using a class factory to create the
classes, and have the factory return the interface. However, I really don't
see the difference between:

Person myPerson;
AddressInterface IAddress;
myPerson = Person.Create;
AddressInterface = myPerson as IAddress;

And:

AddressInterface = Person.Create;

Ultimately though, I would do this:

AddressInterface IAddress = Person.Create;

Only because it saves me three lines of code (as opposed to four or two
in the examples you gave, the second example requires two because you need
the declaration still).

Also, I would only use the interface if there wasn't anything exposed in
the underlying type of the implementation that you needed to access.

Hope this helps.
 
Hi Nicholas,

Thank you for your reply.

What the problem with mixing models with delphi was that if I did the
following:

Person myPerson;
myPerson = Person.Create;

DealWithAddress(myPerson as IAddress); // where parameter is passed
by value.

myPerson.DoOtherThing; // Leads to an access violation.
....

Then once DealWithAddress is finished, the reference count goes down
and myperson is destroy. If I use myPerson I will get an access
violation.

This was true if DealWithAddress had the IAddress parameter by value.

My concern is in C#, would this still occur?

TIA
Steven.

Nicholas Paldino said:
Steven,

I think the question is moot, because if you are going to use an
interface model, then you should be using a class factory to create the
classes, and have the factory return the interface. However, I really don't
see the difference between:

Person myPerson;
AddressInterface IAddress;
myPerson = Person.Create;
AddressInterface = myPerson as IAddress;

And:

AddressInterface = Person.Create;

Ultimately though, I would do this:

AddressInterface IAddress = Person.Create;

Only because it saves me three lines of code (as opposed to four or two
in the examples you gave, the second example requires two because you need
the declaration still).

Also, I would only use the interface if there wasn't anything exposed in
the underlying type of the implementation that you needed to access.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


Steven Quail said:
Hi to all,

Having come from a delphi environment, I remember that when using
interfaces, we were told not to mix the object models and interface
models. In other words, when I create an object, return and interface
straight away, instead of creating an object of type object and then
getting the interface. The reason given for this was that when passing
interfaces around, the interface could
release the object and then if I try to use the object reference, I
would
get access violations.

In C# I have seen examples like:

Person myPerson;
AddressInterface IAddress;


myPerson = Person.Create;
AddressInterface = myPerson as IAddress;

etc.

Is this correct or should I do :

AddressInterface = Person.Create;

In which case I never ever use myPerson.

TIA
Steven.
Click to expand...
Click to expand...
 
You will not have this problem with .NET. The CLR does not engage in
reference-counting; the garbage collector dynamically scans for
orphaned objects in the background. No object is destroyed as long as
there is at least one reference to it somewhere in the application,
whether that reference is typed as an interface, or as the object's
class, or a base class of the object's class.
 
Back
Top