Select Case and Objects

[rbulph]

Is there any way you can use Select Case for comparing objects on the basis of the "Is" operator? e.g to select from a range of possible types:

 

Select Case X.GetType
Case GetType(Class1)

Case GetType(Class2)

End Select

 

This doesn't work because "=" is not defined for the Type Class.

[PlausiblyDamp]

http://www.xtremedotnettalk.com/showthread.php?t=94780 may be worth a read as it started with a very similar question.

[rbulph]

http://www.xtremedotnettalk.com/showthread.php?t=94780 may be worth a read as it started with a very similar question.

Thanks, but the code that I quoted would appear in a plug-in to which I send X, and the plug-in decides what action to take depending on what type of X it has. So I don't see that I can use an interface as the topic suggests because the action can't really be encapsulated in the types of X - it's specified in the plug-in.

[Cags]

Perhaps we could help better if you exlained what the plug-in does.

[PlausiblyDamp]

If you don't have a standard interface you will need to recompile the code everytime you add a new plug-in to the system, that does seem to defeat the point of a plug-in system.

 

It make take a bit of effort to design a suitable interface for your plug-ins but it is the sensible route to take, http://www.xtremedotnettalk.com/showthread.php?t=49597 is most definately worth a look.

[Cags]

I could be wrong but the impression I got from reading the problem as stated by rbulph was that object X isn't the plugin, but is passed to a plugin. So I assumed that the plug-in performs some kind of operation on an object. I can't think what this would help achieve, but thats the impression I got.

[PlausiblyDamp]

My bad, didn't read his post properly :( Still stand by my comment about interfaces being the way to go though...

[rbulph]

It's a sort of information system based on an object model. Each plug in can give information about the objects passed to it in its own way. Perhaps the following example will make things clearer. As you'll see, I've come up with two possible solutions to the Select Case issue, but it would still be good to have a neater one if you can think of it.

 

'Begin Class Library
Public Class BaseClass

End Class

Public Class class1
   Inherits BaseClass
End Class
Public Class class2
   Inherits BaseClass
End Class
Public Class class3
   Inherits BaseClass
End Class

Interface IClassHandler
   Sub HandleClass(ByVal X As BaseClass)
End Interface

'End Class Library

'Begin PlugInA

Public Class PlugInA
   Implements IClassHandler

   Public Sub HandleClass(ByVal X As BaseClass) Implements IClassHandler.HandleClass

       Select Case X.GetType.Name

           Case "class1", "class2"

               MsgBox("This is the situation for Class1s and Class2s")

           Case "class3"

               MsgBox("This is the situation for Class3s")

       End Select
   End Sub

End Class

'End PlugInA

'Begin PlugInB
Public Class PlugInB
   Implements IClassHandler

   Public Sub HandleClass(ByVal X As BaseClass) Implements IClassHandler.HandleClass

       Select Case X.GetType.Name

           Case GetType(class1).Name

               MsgBox("Here's some info about Class1s")

           Case GetType(class2).Name

               MsgBox("Here's some info about Class2s")

           Case GetType(class3).Name

               MsgBox("Here's some info about Class3s")

       End Select
   End Sub

End Class
'End PlugInB

[Cags]

As PlausiblyDamp says it would be a much neater system if this information was retrieved via an Interface. Assuming all the class's passed to the plugin are created by yourself you need to make them implement an Interface which includes a method something along the lines of 'GetInformation'. The current system you are using seems very strange, are the classes being passed into the Plugin not created by yourself, because the only reason I can see for using your current method is if you were going to pass it standard objects, but I can't think what use this would ever be.

[rbulph]

As PlausiblyDamp says it would be a much neater system if this information was retrieved via an Interface. Assuming all the class's passed to the plugin are created by yourself you need to make them implement an Interface which includes a method something along the lines of 'GetInformation'. The current system you are using seems very strange' date=' are the classes being passed into the Plugin not created by yourself, because the only reason I can see for using your current method is if you were going to pass it standard objects, but I can't think what use this would ever be.[/quote']

The classes are created by me. The plug-ins determine what information to give on the basis not only of the type of the object sent to them, but may also use properties of the objects. I don't know what tests they may apply. So surely there's no way that I can achieve this without sending the objects to them for them to perform their tests on?

 

One thing that I didn't do was specify where HandleClass should be called from. On consideration I think this should be done in BaseClass, for good encapsulation. I don't see any need for additional interfaces.

[Cags]

Using the select case statement that you are currently using, every time you add a class you will have to add another item to the case statement. It makes far more sense to create an extra Interface implemented by each class. You will still have the same amount of code but it will be part of the class rather than in the plugin. This way you can add further classes to your application without altering the plugin.

 

I might not be doing a good job of explaining myself here, but hopefully either you'll understand what I'm getting at or somebody else can put it more eliquantly.

[rbulph]

Using the select case statement that you are currently using, every time you add a class you will have to add another item to the case statement. It makes far more sense to create an extra Interface implemented by each class. You will still have the same amount of code but it will be part of the class rather than in the plugin. This way you can add further classes to your application without altering the plugin.

 

I might not be doing a good job of explaining myself here, but hopefully either you'll understand what I'm getting at or somebody else can put it more eliquantly.

What will the classes do in this interface of yours? Select the appropriate plug-in and pass themselves to that, presumably. Essentially the same as I would do in the BaseClass.

 

If I want to add a new class then the plug-ins won't have dealt with it, simple as that. If I've asked the plug-ins to give information about boats, cars and trains, they won't magically be able to give information about airplanes if I later define a new airplanes class. Whatever your interface does (and I'm not quite sure what it would do), it's not going to achieve that, is it? Adding a new class will break compatibility and the plug-ins may need to be rewritten.

[PlausiblyDamp]

If the plugins target the functionality provided by an interface (e.g. all the classes you mentioned are vehicles of some kind and will have a lot of similar functionaility - speed, number of passengers etc, this functionality would be what the interface defines), then the plugin will be able to work with any class that implements the interface without needing to be re-written or re-compiled.

It may help if you give a bit more detail or even some sample code if possible to see if there is an easier solution to your problem.

[Cags]

Are you using the plugins to extend the functionality of classes that are embedded in the main application? Thats the only thing I can think of that you might be trying to do if the Interface method isn't appropriate. For example, given the vehicle scenario.

 

The classes Car, Bike and Bus are all internal classes in the application and have a few methods each. The application also includes a plugin system that passes classes to the plugins (as cast by an interface). After deploying the application you decide that each class should have included a method / property for description.

 

In order to add this method without altering the original application you distribute a plug-in dll. This plugin recieves the object decides what it is and displays a message containing the description depending on the type. This would not help you add a class (for example aeroplane) but would allow you to make some basic additions.

 

Now if this is what your attempting I'm sure there would be a neater solution by making the classes Car, Bike and Bus plugins that implement an interface which is itself seperate from the main application.

 

If that isn't what your attempting then i'm stumped.

[rbulph]

If the plugins target the functionality provided by an interface (e.g. all the classes you mentioned are vehicles of some kind and will have a lot of similar functionaility - speed' date=' number of passengers etc, this functionality would be what the interface defines), then the plugin will be able to work with [i']any[/i] class that implements the interface without needing to be re-written or re-compiled.

It may help if you give a bit more detail or even some sample code if possible to see if there is an easier solution to your problem.

The plug-ins don't really target the functionality of the classes, so much as give information based on the model that they expose. Sure, the plug-ins can always work with any new class that I add, because those classes inherit from the Baseclass. But if it's a new type of object, whoever wrote it can't have considered the information to be given in relation to it, can they? I've already posted some sample code - see above.

 

The addition of new classes to my object model is not really something that I anticipate doing in any case, this was Cags's idea, not mine.

[rbulph]

Are you using the plugins to extend the functionality of classes that are embedded in the main application? Thats the only thing I can think of that you might be trying to do if the Interface method isn't appropriate. For example, given the vehicle scenario.

 

The classes Car, Bike and Bus are all internal classes in the application and have a few methods each. The application also includes a plugin system that passes classes to the plugins (as cast by an interface). After deploying the application you decide that each class should have included a method / property for description.

 

In order to add this method without altering the original application you distribute a plug-in dll. This plugin recieves the object decides what it is and displays a message containing the description depending on the type. This would not help you add a class (for example aeroplane) but would allow you to make some basic additions.

 

Now if this is what your attempting I'm sure there would be a neater solution by making the classes Car, Bike and Bus plugins that implement an interface which is itself seperate from the main application.

 

If that isn't what your attempting then i'm stumped.

 

No I'm not trying to extend their functionality. My plug-ins provide information about the objects passed to them (see the code I posted). Those objects are defined in an object model. Each plug-in will have the opportunity to provide different information as shown in the sample code. Your plug-ins are to do with adding new classes to the object model, which is an entirely different thing. I don't really anticipate doing that, and if I did, I would simply replace the object model, not do it by a plug-in.