I'm sorry, I'm forgetting what the original code was. So, what you want to
do, is analyze the type of object of object coming in, and store the method
in a different place, depending on what it is.

Looking at your code (I know it's for demonstration purposes only) there are
some flaws in the way you are doing it. If you wanted to use interfaces for
this, you probably wouldn't have a WorkFlow class working like that, as
such. If your interface was called IState, say, and it contained a Save()
method, then each object would contain all the code to save it in its own
Save() method. Let me rewrite your code a little. You don't want to be
examining the types of these objects in this core code. This is bad
programming practice as what happens if you decide to derive a new class
from one of your objects? You can add new types, but you cannot easily use
deriving types. The idea behind using an interface here would be to say that
all you care about is that it has a Save() method with the requested
signature. Let's assume that your events class, for example, starts its
definition as follows:

Public Class Events
  Implements IState
  ...

In this class will be the required IState.Save method. Let's assume IState
is defined as follows:

Public Interface IState
  Function Save(db As IStoreRelevantCollection) As Boolean 'Explained
shortly
End Interface

Then the definitions for your similar WorkFlow object class would be as
follows:

Public Class WorkFlow
  Public myCollection As New LotsOfCollection() ' Class shown below and it
implements IStoreRelevantCollection

  Public Function Save(myObject As IState)
    If myObject Is Null Then Throw New ArgumentNullException("myObject")
    Return myObject.Save(myCollection)
  End Function
  ...
End Class

Now we define an interface as follows:

Public Interface IStoreRelevantCollection
	' Classes implementing this interface should make the following
method return false
	Function Save(myObject As Object, name As String) As Boolean
End Interface

Public Class LotsOfCollections
	Implements IStoreRelevantCollection

	Public ReadOnly EventsCollecton As New Hashtable()

	Public Overloads Function Save(myObject As Object, name As String)
As Boolean
		Return False
	End Function

	' Add code for EventsCollection and other relevant collections
End Class

This is now quite well decoupled, and that is what interfaces are used for,
to decouple design from implementation. It specifies that each object must
have a save method, and it is passed a type of object that will store the
object in a relevant collection. This way the .NET Framework will work out
the most appropriate type for each kind of object passed in. If the Object
type is the most relevant, it returns false as there is no relevant
collection type for that object. If you want to create a new class that
accepts your object, you can derive from your original one and add a new
overload, or just create a brand new one (remembering again to implement the
Save() overload specified in the interface).

I could only think how to explain this through example, so please excuse
this long mail. You might be able to think how to do this with less classes.
If you decide to use a lot of Shared Save() methods (and many shared
collections, rather than a shared IStoreRelevantCollection object), then you
can change IStoreRelevantCollection so it has no members.

--
Andrew Polshaw 
Editor and Author for Wrox Press Ltd
Visual Basic .NET Class Design Handbook
C# Class Design Handbook

-----Original Message-----
From: Robert Sindall [mailto:rsindall@z...]
Sent: 07 February 2003 20:40
To: ASPX_Professional
Subject: [aspx_professional] RE: Implementing Interfaces...confused...


Ok well.. I think i get it...

And I don't think its what i want.

I want to create a WorkFlow Object/Class... that I can pass an object to and
it will perform different function depending on the type of the class