|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Changing Interface or Inheritance base classesproject. :) In VB6, I once created a project that exposed a public interface class. I then Implemented this in various plug-in DLLs so that I could early-bind to the plug-ins by declaring objects of the interface class type. This worked fine, until one day I found that I needed to add a new method to the interface class. Of course, everything broke immediately after I had done this as adding a new method changed my class's interface. All the plug-ins that implemented the old interface no longer recognised the new one and I made a big mess that took a lot of time to clear up. This was all based around COM and CLSIDs, neither of which are relevant in VB.NET. Will I have similar problems if I try to change an interface class in a VB.NET project (assuming that I get the plug-ins to bind to the new version and not the old)? In addition to this, I've also been trying to achieve the same objective with inheritance in VB.NET. I have a base class that has a variety of functions that are declared either Overridable (where the function has a default implementation in the base class) or MustOverride (where the derived class has to implement its own functionality). I then get my plug-ins to inherit this class. Code that uses the plug-ins can early bind by declaring objects of the base class type. My assumption is that I can then add new methods to the base class, providing I make them Overridable instead of MustOverride, and the derived classes will continue to function when bound to this modified version of the class. Any calls to the new functions that are unrecognised by the plug-ins will fall through to the base class implementation. Am I correct here, and are there are problems that I may encounter by doing this? My thanks in advance, -- (O) e n o n e I think the generally accepted method of creating new interfaces without
breaking existing ones is to create an entirely new interface that derives from the existing one. Say instead of PlugMeIn_Interface, derive a new one called PlugMeIn_Interface2, deriving from PlugMeIn_Interface. Now, you add the new methods to the new interfaces without changing the way the old interface works. Any new plug-ins you make will utilise the new interface, but old ones obviously cannot (because they don't know about it). Show quoteHide quote "Oenone" <oen***@nowhere.com> wrote in message news:mNZ3e.8839$kr.2957@newsfe1-gui.ntli.net... >I could use a little advice to help prevent me making a possible mess of a > project. :) > > In VB6, I once created a project that exposed a public interface class. I > then Implemented this in various plug-in DLLs so that I could early-bind > to > the plug-ins by declaring objects of the interface class type. > > This worked fine, until one day I found that I needed to add a new method > to > the interface class. Of course, everything broke immediately after I had > done this as adding a new method changed my class's interface. All the > plug-ins that implemented the old interface no longer recognised the new > one > and I made a big mess that took a lot of time to clear up. > > This was all based around COM and CLSIDs, neither of which are relevant in > VB.NET. Will I have similar problems if I try to change an interface class > in a VB.NET project (assuming that I get the plug-ins to bind to the new > version and not the old)? > > In addition to this, I've also been trying to achieve the same objective > with inheritance in VB.NET. I have a base class that has a variety of > functions that are declared either Overridable (where the function has a > default implementation in the base class) or MustOverride (where the > derived > class has to implement its own functionality). I then get my plug-ins to > inherit this class. Code that uses the plug-ins can early bind by > declaring > objects of the base class type. > > My assumption is that I can then add new methods to the base class, > providing I make them Overridable instead of MustOverride, and the derived > classes will continue to function when bound to this modified version of > the > class. Any calls to the new functions that are unrecognised by the > plug-ins > will fall through to the base class implementation. Am I correct here, and > are there are problems that I may encounter by doing this? > > My thanks in advance, > > -- > > (O) e n o n e > > Robin Tucker wrote:
> I think the generally accepted method of creating new interfaces Hi Robin,> without breaking existing ones is to create an entirely new interface > that derives from the existing one. Thanks for your reply. That was the conclusion we came to too in the end (back in VB6), but we decided it was more trouble than it was worth in the end and just late-bound to the components. Do you (or anyone else) have any comments on the inheritance method I described? This it the one I really want to go with in VB.NET but I'm not quite at the point of being able to test it yet... Thanks, -- (O)enone |
|||||||||||||||||||||||