Passing object as interface
Erwien Saputra
Usually I was consistent, either use interface or object. But when I
was experimenting, I found this:
type
TMyObject = class(TInterfacedObject, IVisited, IInfo)
...
end;
TForm1 = class(TForm)
private
FMyObject : TMyObject;
procedure Test(Visited : IVisited);
published
procedure Button1Click();
end;
implementation
procedure TForm1.Button1Click();
begin
//I do something here with FMyObject;
Test (FMyObject);
//in here, FMyObject has been freed. Exception was thrown.
end;
It seems that I cannot pass object to method that require interface. Is
that true?
Wien.
Paul Nicholls
think you should define it as a IVisited in the firstplace to work correctly
with reference counting...
--
Paul Nicholls (Delphi 5 Professional)
"Life is like a road - occasionally you run into potholes or get blowouts." -
Paul Nicholls
HomePage: www.southcom.com.au/~phantom
Email: paul_f_...@antispam.hotmail.com
(Remove "antispam." to reply)
"Erwien Saputra" <erw...@nospam.codeline.dot.net> wrote in message
news:3CC8E3C4...@nospam.codeline.dot.net...
Erwien Saputra
> I think you could try passing the object as a const interface instead, but I
> think you should define it as a IVisited in the firstplace to work correctly
> with reference counting...
I searched the newsgroup and found the solution. I shouldn't mix object
reference and interface reference. Usually I didn't. :)
As I post in my previous post, my object implements IVisited and IInfo.
I actually need to work with both interfaces. That's why I declare my
object not as interface.
What is the best way to declare FMyObject then?
1) FMyObject : TMyObject; then query the interfaces as needed (as
IVisited or IInfo)
2) FMyObject : IVisited; then query IInfo as needed
or 3) FMyObject : IInfo; then query IVisited as needed?
Thanks!
Wien.
Paul Nicholls
--
Paul Nicholls (Delphi 5 Professional)
"Life is like a road - occasionally you run into potholes or get blowouts." -
Paul Nicholls
HomePage: www.southcom.com.au/~phantom
Email: paul_f_...@antispam.hotmail.com
(Remove "antispam." to reply)
"Erwien Saputra" <erw...@nospam.codeline.dot.net> wrote in message
news:3CC8EEB1...@nospam.codeline.dot.net...
Joanna Carter
You should always use const for interface parameters as this avoids
rerference counting overhead on the way in and out of the method, as do
strings.
Joanna
Joanna Carter
news: 3CC8EEB1...@nospam.codeline.dot.net...
> I searched the newsgroup and found the solution. I shouldn't mix object
> reference and interface reference. Usually I didn't. :)
Definitely agreed.
> What is the best way to declare FMyObject then?
As trhe type it is modt used as, usually something like IInfo. If you really
wanted to not yype it one way or the other, then you couold use IInterface,
but this is not a good idea.
Joanna
Joanna Carter
3cc9007f_2@dnews...
> As trhe type it is modt used as, usually something like IInfo. If you
really
> wanted to not yype it one way or the other, then you couold use
IInterface,
> but this is not a good idea.
Sorry I hadn't put my glasses on and I was touch typing.
<glasseson>
As the type it is most used as, usually something like IInfo. If you really
wanted to not type it one way or the other, then you couold use IInterface,
but this is not a good idea.
</glasseson>
Joanna
Rudy Velthuis (TeamB)
Well, yes and no.
If you create it immediately, and don't cast (this is possible,
syntactically), your reference will be lost. I did something like:
procedure DoThat(const Some: IsomeIntf);
var
Other: IOtherIntf;
begin
if Supports(Some, IOtherIntf, Other) then
begin
// use Other
end;
end;
procedure DoThis(const Some: ISomeIntf);
begin
DoThat(Some);
Some.ShowYourName;
end;
DoThis(TImplementorOfBothInterfaces.Create);
This crashed at Some.ShowYourName, because on entry to DoThis, the
reference count of Some was 0 (no problem so far), in DoThat it was
incremented to 1 and at the end of DoThat decremented to 0 again -- and
freed.
Using an explicit "as" solved this:
DoThis(TImplementorOfBothInterfaces.Create as ISomeIntf);
But IMO, this "as" should be done implicitly as well, when assigning an
object to an interface reference.
--
Rudy Velthuis (TeamB)
"If we knew what it was we were doing, it would not be called research,
would it?" -- Albert Einstein
Erwien Saputra
> <glasseson>
> As the type it is most used as, usually something like IInfo. If you really
> wanted to not type it one way or the other, then you couold use IInterface,
> but this is not a good idea.
> </glasseson>
I am wearing glasses too, don't worry about it! :)
Can you please explain why it is not a good idea to use IInterface?
Actually I was thinking to do that.
It seems that I have to use Interface or Object consistently, but not
both at the same time.
Please tell me is this interpretation right or not:
Inheritance = is-a relationship (TDog is TAnimal)
Interface = can-do relationship (TDog can do IEat)
Wien.
Joanna Carter
news: 3CC99104...@nospam.codeline.dot.net...
> Can you please explain why it is not a good idea to use IInterface?
> Actually I was thinking to do that.
When you are using interfaces, you should find that there is usually one
role that the implementing class fulfils most of the time, its primary role.
If someone else were to come along and look at code that contains variables
of IInterface, there is very little that you can assume about the kind of
object you are dealing with. Better to use an interface ref of the type most
suited to the primary role.
> It seems that I have to use Interface or Object consistently, but not
> both at the same time.
Ideally, for the sake of your sanity, don't mix holding references to
objects in both class type pointers and interface type pointers. There are
issues of lifetime management and reference counting that can cause many
problems.
Interfaces are not just a neat trick to use with objects, they are a
different attitude to programming, sometimes called programming by contract.
> Please tell me is this interpretation right or not:
>
> Inheritance = is-a relationship (TDog is TAnimal)
> Interface = can-do relationship (TDog can do IEat)
Yes, but don't forget you should also have
inheritance
IDog = is-a relationship IAnimal
can do
TDog can-do IDog and can-do IEat
Joanna