Alternative to Interface?

[Brett]

I have created an interface with five properties and five methods. Five
classes are accessed through this interface and contain the implementation.
This setup works fine now. All the classes are encapsulated by the
interface.

If one of the classes requires a new method, this means I have to add this
method to the interface and all involved classes. My design breaksdown in
this case and becomes high maintenance. Is there a better approach to this
scenario or some way to overload the interface?

Thanks,
Brett

 

[W.G. Ryan eMVP]

Brett - why not just add the method to the class in question as opposed to
adding it to the interface?

 

[Bob]

1. Why are you using an interface (is it necessary)?
2. Do *all* methods/properties have to be represented in an interface?
3. If so, must they all be in one?

Post your code (maybe attach a plain text file so the line breaks aren't
mangled). Maybe also include a breif functional description of what you need
to do.

Bob

 

[Brett]

I use the interface to avoid switch statements. In the main form, I pass
the class name into a method. Inside that method are references using the
interface via the class name parameter passed in. There is much processing
done that makes use of data stored inside of these encapsulated classes. If
I had not done this, IFs or case statements would be required for explicit
references to each class. This shortens my code and keeps maintenance down.

For example, in the form, I do:

Private mailClientRef As IWebmailclients.Iwebmail

Private Sub btnSubmit_Click()
InitInterface(Me.mcClass1)
StartIt()
End Sub


Private Sub InitInterface(ByVal mailClientRefparam As
IWebmailclients.Iwebmail)
Me.mailClientRef = mailClientRefparam
End Sub

In the StartIt() method, I only need to reference mailClientRef.methodname
or property. That's why I use the interface.

Brett

 

[Oenone]

If one of the classes requires a new method, this means I have to add
this method to the interface and all involved classes. My design
breaksdown in this case and becomes high maintenance. Is there a
better approach to this scenario or some way to overload the
interface?

I examined the same problem and decided in the end to use inheritance
instead of interfaces to solve the problem.

I declared my base class as MustInherit, and into it I put all of the
properties and methods that I wanted my derived classes (plug-in DLLs in
this instance) to support. Some of the methods had to be implemented in the
derived classes, so I declared these as MustOverride. Others could be left
with either an empty implementation or could fall back to a default
implementation provided by the base class itself. These I declared
Overridable (after finally working out how to spell "Overridable").

This works very nicely; when I want to use one of the plug-ins, I can
declare an object with the type of the base class, and then set it to one of
the derived classes. This lets me early-bind to all the plug-in classes.

When I want to add a new property or method to the base class, as long as I
declare it as Overridable instead of MustOverride, everything continues to
work perfectly. You can therefore add as many new functions as you like,
providing they can fall back to the implementation in the base class when
the derived class doesn't override them.

 

[Herfried K. Wagner [MVP]]

I have created an interface with five properties and five methods. Five
classes are accessed through this interface and contain the implementation.
This setup works fine now. All the classes are encapsulated by the
interface.

If one of the classes requires a new method, this means I have to add this
method to the interface and all involved classes. My design breaksdown in
this case and becomes high maintenance. Is there a better approach to
this scenario or some way to overload the interface?

Add the method to one of the classes only if it doesn't make sense for the
other classes. Place only those methods and properties in the interface
which are part of the interface's contract. In other words, only add
methods and properties to an interface which semantically belong to the
interface. Otherwise your code will be hard to understand and maintain.

 

[Brett]

I examined the same problem and decided in the end to use inheritance
instead of interfaces to solve the problem.

I declared my base class as MustInherit, and into it I put all of the
properties and methods that I wanted my derived classes (plug-in DLLs in
this instance) to support. Some of the methods had to be implemented in
the
derived classes, so I declared these as MustOverride.

By the way, is MustOverride the same as Java's abstract? Or what is the VB
equivalent of abstract?

Others could be left
with either an empty implementation or could fall back to a default
implementation provided by the base class itself. These I declared
Overridable (after finally working out how to spell "Overridable").

This works very nicely; when I want to use one of the plug-ins, I can
declare an object with the type of the base class, and then set it to one
of
the derived classes. This lets me early-bind to all the plug-in classes.

When I want to add a new property or method to the base class, as long as
I
declare it as Overridable instead of MustOverride, everything continues to
work perfectly. You can therefore add as many new functions as you like,
providing they can fall back to the implementation in the base class when
the derived class doesn't override them.

Your approach is good. Actually, after rethinking my situation, I believe
the Interface is best. All of these classes should have exactly the same
methods and properties. Otherwise, my main form will have to make
decisions. If I do an override and certain classes fall back into the base,
I'll have to be sure it is handled correctly. That for every new addition
of a method.

I will instead encapsulate the function of any new method inside of an
existing method. If one class becomes a special case and requires a new
method, that functionality will instead be placed into an existing method.
This way, everything continues to work as before. If only there were a way
to encapsulate that specific piece of special case functionality.

If it is an across the board method addition, changes are required to the
interface, all encapsulated classes and the form. So an entire mod to the
app, which it should be.

Brett

 

[Brett]

Add the method to one of the classes only if it doesn't make sense for the
other classes. Place only those methods and properties in the interface
which are part of the interface's contract. In other words, only add
methods and properties to an interface which semantically belong to the
interface. Otherwise your code will be hard to understand and maintain.

You're right. All of these classes interacting with the interface
conceptually do the samething and look the same. Implementations differ
slightly but the special case may arise. I would like to take any special
case code and put it into a method. Is there a way to encapsulate it? I
can't put it into its own method because of the Interface. Is there another
way to encapsulate this?

Thanks,
Brett