• Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.NET Generic constraints

ASB

Godlike
Thanks received
91
I don't think I can do this but......

I have a base Class - say "tool"

I have a number of derived classes. Say, "hammer", "chisel", "screwdriver", "spanner"

I want to create a generic class that will operate on a "hammer" or a "chisel".

I can't do this because you can only have one constraint in a class class.

The actual Inheritance looks like this:-

Message

OutputMessage - these I want to operate on
out1
out2
.....

InputMessage - these I want to operate on in the same way
in1
in2
.....


Any thoughts on my mission to push back the boundaries of good implementations?
 
Apologies if I've misunderstood, but you can have multiple constraints on a generic class: http://msdn.microsoft.com/en-us/library/d5x73970(VS.80).aspx

Yep I probably didn't make myself entirely clear. Don't seem to be able to have them in the way I want.

Consider:-

Public MustInherit Class message

End Class

Public MustInherit Class outputMessage
Inherits message
End Class

Public Class out1
Inherits outputMessage

End Class

Public Class out2
Inherits outputMessage

End Class

Public MustInherit Class inputMessage
Inherits message

End Class

Public Class in1
Inherits inputMessage

End Class

Public Class in2
Inherits inputMessage

End Class

Public Class Wibble(Of T As message)
End Class

What I want to be able to do (and I'm pretty sure I can't!) is

Public Class Wibble(Of T As message where T is inputmessage or outputmessage)
End Class

The idea is to construct the class as:-

dim o as new Wibble(inputMessage)
dim o as new Wibble(outputMessage)

I think a bit of refactoring is in order..
 
Strategy pattern?

Not sure I understand but is it that you want to delegate work off to other classes so taking the first example, you create a new tool object and you tell it to do work. Now if your tool object is of type hammer, the doWork method, hammers, if its of type chisel, the doWork method chisels.

If this is what you're after, interfaces are the way to go.

Or have I got the wrong end of the stick (as usual).
 
Strategy pattern?

Not sure I understand but is it that you want to delegate work off to other classes so taking the first example, you create a new tool object and you tell it to do work. Now if your tool object is of type hammer, the doWork method, hammers, if its of type chisel, the doWork method chisels.

If this is what you're after, interfaces are the way to go.

Or have I got the wrong end of the stick (as usual).

I've just knocked up a wrapper and pass it in to the instance I want. The problem with interfaces is that they are available on any further derived classes and I didn't want that either.
 
I've just knocked up a wrapper and pass it in to the instance I want. The problem with interfaces is that they are available on any further derived classes and I didn't want that either.

Perhaps you need to use composition rather than inheritance then.
 

Advertisers

Back
Top