[AccessD] Implements vs WithEvents

Well, I couldn't resist putting in my own (tardy) views on Implements in
VBA:

An interface is a communication protocol - a set of signatures denoting the
public properties and methods of a class. Every class has its default
interface, which is just its own properties and methods. In A2K and later,
you can have a class support any published interface available to it. For
example, IDTExtensibility2 is a published interface that allows you to write
Office COM Add-ins. Part of writing an Add-in is implementing this
interface.

You can also design and implement your own custom interfaces. An interface
is simply a class module with the desired properties and methods defined -
but no code or variables. I prefix interfaces with an I, like ITreeClient,
and use C for standard classes, like CTree.

Implementing an interface COM-enables your class. While that doesn't make
much practical difference in VBA, interfaces are the foundation of COM
programming.

Interfaces differ from contracts in that a contract guarantees a certain
result for a given set of inputs. The interface simply guarantees that a
certain set of properties and methods are present - but says nothing about
results.

While Implements has little to do with inheritance, it has lots to do with
polymorphism. The most common use of Implements in VBA is to define a custom
interface that is shared across many objects. So, every Dog class can
implement IObedience, and thus accept the commands Sit, Rollover and Fetch.
Note that the interface doesn't guarantee that the individual classes will
do anything useful or correct with the commands (much like real dogs). No
functionality is inherited. For that, as has been pointed out, you will have
to go to VB.Net.

It is also worth noting that most of what you can do with interfaces you can
also do with late binding. For instance, the Dog classes could each have the
methods Sit, Rollover and Fetch defined in their default interfaces. You
would use them like this:
    Dim rDog as Object
    Set rDog = New CPoodle    ' or CHusky, etc
    rDog.Fetch                ' late bound

With a custom interface, the same code would be:
    Dim rDog as IObedience
    Set rDog = New CPoodle
    rDog.Fetch

There are at least three advantages to the interface approach:
 1. Early binding - can be significantly more efficient
 2. Compile-time checking - protects against incomplete/incorrect interface
implementations
 3. Early trapping of runtime errors - if an object doesn't implement
IObedience, say CSiamese, you will know immediately on the Set command -
you'll get a Type Mismatch error.

You can also query an object to see if it supports a particular interface:
    If TypeOf rObj Is IObedience Then
        Set rDog = rObj
        ' do dog things

As for interfaces and events, the advantages of each are a little more
subtle. Events are broadcast, so every object subscribing to an event using
WithEvents will get the message. A problem can arise when you are managing a
group of objects, and want to send a message to only one of them. Using
events, every object in the group would have to ask 'Is this for me?' when
they received the event. This can get cumbersome, especially if there is a
lot of communication going on.

Interfaces allow you to define your own custom callback scheme. You can then
select an object out of a group, and send a message only to it. This is more
efficient and reliable than the broadcast method. I use this, among other
things, to control interactions between forms. Form class modules support
Implements beautifully.

So, when defining your object communication scheme, interfaces give you more
options. If everybody needs the message, an event would be a good choice. If
only a few members out of the group need it, perhaps an interface-based
callback would be better.

Another limitation to be aware of: you can't define useable shared events in
a VB custom interface.

I have found interfaces to be quite handy in situations where I want many
objects to behave the same way, or when I want to control specific objects
in a group, rather than talk to all of them. While they are not ideal,
interfaces are still a useful and powerful concept in their present form.
Thinking in terms of interfaces helps me introduce rigor into my object
structures. In closing, I'd like to credit the authors of Effective Visual
Basic, by DevelopMentor, for their excellent introduction to interfaces.

-Ken