[AccessD] Implements vs WithEvents

Ken,

Thanks for that.  As I said, I don't use Implements, never having found a
use for them.  I therefore don't really understand the ins and outs as I do
withevents.  Indeed, having been focusing so long on Access which does not
have inheritance I have pretty much lost my ability to speak intelligently
about the subject although I am getting back into it with VB.NET.

I guess back when I used this stuff (early 90s with Object Pascal and C from
Borland), interfaces weren't really used much?  I studied, used and became
comfortable with inheritance and miss it sorely in Access / VBA.  Coming
from a background where you do indeed inherit EVERYTHING from the parent
class I guess I failed to see enough use for Implements to take a close
look.

One thing you say intrigues me though.  You mention Implements allowing a
custom callback scheme and sending messages.  How does this work?  How does
the callback communicate between class instances?

I wrote a messaging class using Withevents and RaiseEvents.  Set up one or
more global instance(s) of the class and off you go.  The class has a method
that accepts a message and raises an event passing the message on to any
listeners.  Thus I can instantiate the class for a specific purpose, only
the classes that care to listen do so, although of course if there are 1000
instances of that class then they all listen and must, as you say, decide
whether the message is for them.  In the case of forms however, I can set up
a private message channel between any two or more forms.  The message class
also can broadcast a "from/to/subject/message" so that any listeners can
just check the to:.  In fact that is exactly how I use it between forms, I
just include the form name that is the intended recipient and all forms
check the to: for their own name and accept the message if they need to.

How is this stuff done with Implements?

And BTW, a little less OBTUSE if you would.

;-)

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ken Ismert
Sent: Thursday, January 15, 2004 1:13 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [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

_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com