Re: Interfaces...am i missing the point?

dvddude wrote: 
I have learned that when i include an interface as part of an object...

    TMyObject = class(Tobject, IMyInterface)

I then have to implement all the functions/procedures defined in the interface, inside my object?? 

Correct.

So why have to interface in the first place, why not just create all the function as methods of the object as i'll have to do that anyways.

If you have two interfaces, then you have to declare methods for both of them in the same object. Any descendants of that object will inherit all those methods, even if for some of the descendants it doesn't make sense to have all those methods. If *any* of the objects in the hierarchy will need to have some methods, then *all* of them would need to have them. With interfaces, you can insert the same interface in several places mid-hierarchy, so as Maarten suggested, you could insert an interface to TEdit and TPanel without having to change TControl or interfere with TButton and TLabel.

There are also some neat delegation tricks you can use, so multiple objects can appear as though they're all the same object.

Furthermore, any language that understands interfaces can use them the same way. You can't pass a TObject to a C++ program and expect it to do anything -- and you definitely can't pass a C++ object to Delphi and get anything useful from it -- but you can pass an IMyInterface reference to both those languages and they'll know exactly what to do.

Surely, i should define the interface and the methods that go with that interface, then when i ant to use the interface, say in multiple components, i don;t have to start over writing all the method code again..

That would be great, if you knew how to implement those methods for *all* possible objects that would claim to implement the interfaces. What you're talking about is multiple inheritance.

What happens with Interfaces and COM? If I define the interface, how do i define the methods, when i want the interface to call code in a com server?

That's just it -- you don't define the methods. All you do is declare them. They're implemented in the COM server. The interface specifies a common set of methods, their parameters, and their order of declaration, so any language that supports COM can use them. They don't even necessarily need to be implemented by objects. The C language doesn't support objects, for instance, but you can still use that language to implement COM servers.

I'm having trouble getting my head around this!

An interface is a way of saying, "This object can perform this set of operations." What an interface does not do is specify *how* the object accomplishes those operations. After reading the documentation for the IMyInterface interface, it shouldn't matter how you get a reference to something that implements that interface. However you manage to get a reference, once you have it, it should be as good as any other because everything will implement the same set of methods.

XML libraries are a good example. Borland declares lots of XML interfaces, mainly based on the W3C DOM specifications. Borland then provides several other units that all contain objects implementing those interfaces. One implementation is based on Microsoft's XML library. Another implementation is done entirely in Delphi code. They're two very different implementations, and it would probably have been difficult to adapt them both to the same object hierarchy because there would be very little in the way of implementation code that they could share. The only things they could end up sharing would be a set of abstract methods, and a class with all abstract methods is essentially an interface. When using the XML interfaces, the library-specific code is very limited. All you do is call the single library-specific function to create an instance of the IDomDocument interface, and from there you just call that interface's methods. The code that _uses_ the XML objects doesn't need to know anything about which implementation is in use.

--
Rob
.