Expanding "Interface" explanation

[QuimV]

Hi,
In the PureBasic help in the "Interface" page, there is a brief explanation that I do not quite understand (in order to use it of course).
Could someone point me to a link(s) where I can expand the information of the "Interface" page?
Thanks in advanced
QuimV

[mk-soft]

Interfaces are available for access using early binding to COM objects (OOP).
Extends for inheritance of interfaces.

The description in the help are not very helpful and there are advanced programming skills required.

But can one use for good object-oriented programming in PureBasic.

Links:
http://www.purebasic.fr/english/viewtop ... 12&t=64305
http://www.purebasic.fr/english/viewtop ... 12&t=63132

Discussion:
http://www.purebasic.fr/english/viewtop ... =7&t=64624

COM-Objects (Germany)
http://www.purebasic.fr/german/viewtopi ... =9&t=22518

[QuimV]

Hi mk-soft,
You are ever available for everybody
thank you so much for you quickly answer
QuimV

[mk-soft]

Here is a working example with the minimum requirement for an Object
as a module

Code: Select all

; Own Object

DeclareModule MyObject
  
  ; Defined a list of methods
  Interface iMyObject
    Release()
    Put(value.s)
    Get.s()
  EndInterface
  
  ; Defined a structure of object
  Structure sMyObject
    *vTable ; Allways as first. Pointer to the function table of the methods
    ; List of properties
    value.s
  EndStructure
  
  Declare New()
  
EndDeclareModule

Module MyObject
  
  ; Defined methods
  
  Procedure Release(*this) ; The first parameter of the method is allways a pointer to the own object
    FreeStructure(*this)
  EndProcedure
  
  Procedure Put(*this.sMyObject, value.s)
    With *this
      \value = value
    EndWith
  EndProcedure
  
  Procedure.s Get(*this.sMyObject)
    Protected result.s
    With *this
      result = \value
    EndWith
    ProcedureReturn result
  EndProcedure
  
  ; The function to create a new object
  
  Procedure New()
    Protected *result.sMyObject
    *result = AllocateStructure(sMyObject)
    If *result
      *result\vTable = ?vMyObject ; Set´s the pointer to virtual table of methods
    EndIf
    ProcedureReturn *result
  EndProcedure
  
  DataSection ; Virtual function table of methods. Same order as the interface
    vMyObject:
    Data.i @Release()
    Data.i @Put()
    Data.i @Get()
  EndDataSection
  
EndModule

; Test

Define.MyObject::iMyObject *obj1, *obj2
Define r1.s

*obj1 = MyObject::New()
*obj2 = MyObject::New()
*obj1\Put("Hello ")
*obj2\Put("World!")
r1 = *obj1\Get() + *obj2\Get()
Debug r1
*obj1\Release()
*obj2\Release()

[srod]

Interfaces are very straight forward. It's easy to think that they are more complex than they actually are.

If your program calls some function or other (e.g. a function inside a DLL) and that function returns an 'interface pointer', then what you have is a simple way of calling a whole bunch of closely related functions (now called 'methods') in that DLL through that single pointer. That's it! Nothing more! The interface pointer simply points, indirectly at least, to a table of function addresses.

From a PB coder's point of view, it allows us to easily use COM objects for example (since COM objects expose their functionality through interface pointers). Just as importantly, however, is that we can easily create our own simple OOP classes through simple interfaces.

I much prefer to create libs which expose simple OOP classes (as opposed to myriads of functions) since they allow me to bundle together all related functions and their associated data. It also keeps, in the case of a dll, the method names hidden from prying eyes because individual methods are not exported (made public) in the dll. No amount of snooping through the DLL binary will reveal the method names.

For example, I am just this minute making use of a simple class I created for dealing with a stack of integers. When one of my apps needs to use such a stack it simply calls a function in the stack lib. This function simply allocates memory for a suitable stack, sets a few member variables and returns a suitable interface pointer.

Through this pointer I can then call functions to push/pop integers as I see fit.

If I then create a second stack through the aforementioned creation function, I get a second separate interface pointer and a separate distinct stack. I can use the two interface pointers to push/pop away at my heart's content and at no time will one of the stacks interfere with the other. In this sense you can see that each interface pointer not only provides access to the appropriate functions for dealing with the stacks, but also, keeps all the relevant data structures etc. neatly packaged away behind the scenes.

I can probably hack up some example if you wish me to.

**EDIT : too late!

[QuimV]

Hi Srod,
Your explanation is quite clear.
Colud you give me a short example?
Thanks in advance.
QuimV

[srod]

Ages ago I wrote a simple manual/tutorial for using simple OOP via interfaces with PB. It discusses the ins and outs of interfaces and virtual tables etc. and develops a simple rectangle class.

I am happy to email it to you if you wish. Just pm me an email address.

mk-soft's example shows everything there is, but I agree that it can be a little confusing the first time you encounter a virtual table etc.

[mk-soft]

I have revised the description of the example

[QuimV]

Hi srod,
Could you please, send me this manual by email?
Thanks a lot
QuimV

[davido]

@srod,

Thank you for a nice description of Interfaces.
Could your 'Manual' be made available to all in some way?

[srod]

My company webspace is not somewhere I wish to upload files to at this time.

pm me an email address and I will send out a copy.

[Little John]

**EDIT : too late!

Noooo, not too late.
Your explanation and mk-soft's example code complement each other very well.
Many thanks to the two of you!

[davido]

@srod,

Thank you for taking the time to explain 'Interface'.
The zip, containing the manual, was received intact: Manual and two .pb demo files.