-
Nov 28th, 2017, 10:36 PM
#1
Thread Starter
New Member
"conditional" dim type
Hello All.
I have a procedure I call from 2 different areas in my app/
The procedure does the same thing for both situations, but in one case must have one of its internal variables declared as type A and in the other case the same variable must be declared as type B.
So, the following obviously does not work, I am aware that you can not do a Dim inside and if statement. This is where I need a solution. A non-declared variable would work, but i like it better for 'clean' & ease programming and intellisense.
Code:
Public Sub FillHistoryGrid(ByRef TempmyVar)
If condition = true Then
Dim myVar As New List(Of Type5)
Else
Dim myVar As New List(Of Type6)
End If
myVar = TempmyVar
...
end sub
Any ideas?
Thanks for all your help!
-
Nov 28th, 2017, 11:31 PM
#2
Re: "conditional" dim type
There may not be any "ideal" solution to your problem but there may be things you can do. Those things would depend on the specifics of the situation though, and you haven't provided enough of those specifics. Please explain what you're actually trying to achieve, rather than how you're trying to achieve it. We can then recommend the best way(s) to achieve that aim, rather than trying to torture a solution to what might not even be the right problem. For instance, it may be that that simply writing a generic method is the best option, or overloading a method, or using a non-generic interface, or something else. Your explanation is simply too vague to really know. We need more specific details.
-
Nov 29th, 2017, 05:32 AM
#3
Addicted Member
Re: "conditional" dim type
Not sure if this helps you, but are you familiar with the concept of overloading?
https://msdn.microsoft.com/en-us/library/ms973896.aspx
Utterly useless, but always willing to help
As a finishing touch god created the dutch
-
Nov 29th, 2017, 06:29 AM
#4
Fanatic Member
Re: "conditional" dim type
Sounds like you just need late binding
never tried it in .NET but it would go something like this
in a module just declare a variable
'Public MyVar'
then in an if statement you can something like
'Set MyVar = New Object
then after your finished
Set MyVar = Nothing
again i have never tried to do this in .Net but its something ive don in VBA which works...... so im sure someone will shout out if it doesnt work
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 07:22 AM
#5
Re: "conditional" dim type
Originally Posted by GBeats
Sounds like you just need late binding
Late binding should be a last resort. It may be the best solution but there may be much better options, depending on the specifics of the situation.
-
Nov 29th, 2017, 07:27 AM
#6
Fanatic Member
Re: "conditional" dim type
Originally Posted by jmcilhinney
Late binding should be a last resort. It may be the best solution but there may be much better options, depending on the specifics of the situation.
i agree, there is alot of overhead doing this but for simple tasks ive never encountered a problem..... i wouldnt do this in a large tight loops for example but for something trivial like a button press its not going to cause a problem really...
im sure jmc has a rebuttal
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 07:29 AM
#7
Re: "conditional" dim type
The fact that you've never encountered a problem doing something is no reason to do it if there are better options.
-
Nov 29th, 2017, 07:29 AM
#8
Re: "conditional" dim type
I would avoid late binding if possible as you lose all type safety and errors are much harder to track down.
Without further detail as to what is needed I think jmcilhinney's suggestion of a Generic Method is probably the best.
Code:
Public Sub FillHistoryGrid(Of T)(ByRef TempmyVar As List(Of T))
Dim myVar As New List(Of T)
myVar = TempmyVar
End Sub
although without knowing what the "condition" is in the original post I could be completely wrong here.
-
Nov 29th, 2017, 07:32 AM
#9
Fanatic Member
Re: "conditional" dim type
Originally Posted by jmcilhinney
The fact that you've never encountered a problem doing something is no reason to do it if there are better options.
i sense alot of hostility from you.....
im merely giving an option that may work which the OP hasent yet received.... im just trying to help....
if you have better ideas then great you know ill listen. no need to be so... 'in my face about it '
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 07:51 AM
#10
Re: "conditional" dim type
Originally Posted by GBeats
i sense alot of hostility from you.....
im merely giving an option that may work which the OP hasent yet received.... im just trying to help....
if you have better ideas then great you know ill listen. no need to be so... 'in my face about it '
You're making the mistake of interpreting criticism of your idea as a personal attack. I'm just stating facts. As I stated clearly, late-binding might be the best solution but there's no way to tell based on the information provided. If it turns out to be the best option then I'll whole-heartedly endorse the idea but if the OP just goes ahead and uses late-binding without considering whether it's the best option then they do themselves a disservice. There are a number of tools available in VB.NET that don't exist in VB6 or VBA (interfaces, generics and maybe overloading), so late-binding is needed far less often.
-
Nov 29th, 2017, 08:00 AM
#11
Fanatic Member
Re: "conditional" dim type
Originally Posted by jmcilhinney
You're making the mistake of interpreting criticism of your idea as a personal attack. I'm just stating facts. As I stated clearly, late-binding might be the best solution but there's no way to tell based on the information provided. If it turns out to be the best option then I'll whole-heartedly endorse the idea but if the OP just goes ahead and uses late-binding without considering whether it's the best option then they do themselves a disservice. There are a number of tools available in VB.NET that don't exist in VB6 or VBA (interfaces, generics and maybe overloading), so late-binding is needed far less often.
well i apologize.
i do see how an overloaded class would also help here, never tried it but setting up several known types within the class waiting to be initialized with a certain overloaded initializing function would prevent late binding would give a little overhead but an explicit variable to use.... i think the pros far out way the cons really thinking about it compared to late binding which i know is a nightmare to troubleshoot....
Actually thinking about it, you could probably set up a class to include every type available and overload it. call it a managed late binding class
not sure how that might work in terms of overhead but i think im going to try it.
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 08:39 AM
#12
Fanatic Member
Re: "conditional" dim type
@OP
ok i came up with something that may work...... its very basic and someone will elaborate i hope..
Code:
Public Class ManagedLateBinding
'These structures could be put in a module so they are available to your code anywhere you need them
Private Structure Type1
Const TypeName As String = "Type1"
Dim var1 As String
Dim var2 As Integer
End Structure
Private Structure Type2
Const TypeName As String = "Type2"
Dim var1 As Boolean
Dim var2 As Single
End Structure
Private StructureUsed As Integer
Private Structure1 As Type1
Private structure2 As Type2
Public Sub New(str As String, int As Integer)
'put code here to populate structure 1
StructureUsed = 1
End Sub
Public Sub New(bool As Boolean, sin As Single)
'put code here to populate structure 2
StructureUsed = 2
End Sub
Private Function FindType() As Object
Select Case StructureUsed
Case 1
Return (Structure1)
Case 2
Return (structure2)
Case Else
Return (Nothing)
End Select
End Function
ReadOnly Property ReturnData As Object
Get
Return FindType()
End Get
End Property
End Class
so this class you would initialize and set up the required fields with the datatypes required to populate a pregiven type/structure (or make a class instead of structure).
this kind of methods means you need to know beforehand what objects/datatypes your using but you can setup functions to return various types of data based on the type used etc etc.... or dump the entire data into an object(just like late binding but, you can troubleshoot errors from the class data easily)
im pretty sure this could get very complex but i think this could certainly work for u with a bit of tweaking.
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 09:20 AM
#13
Re: "conditional" dim type
Meanwhile the OP has gone MIA... so we may never know what it is they needed...
-tg
-
Nov 29th, 2017, 09:27 AM
#14
Re: "conditional" dim type
Originally Posted by PlausiblyDamp
I would avoid late binding if possible as you lose all type safety and errors are much harder to track down.
Without further detail as to what is needed I think jmcilhinney's suggestion of a Generic Method is probably the best.
Code:
Public Sub FillHistoryGrid(Of T)(ByRef TempmyVar As List(Of T))
Dim myVar As New List(Of T)
myVar = TempmyVar
End Sub
although without knowing what the "condition" is in the original post I could be completely wrong here.
Generics would seem to be the way to go.
-
Nov 29th, 2017, 10:28 AM
#15
Re: "conditional" dim type
I think PD's answer #8 is probably the right path.
What JMC touched on is there's likely a different and better solution to this problem. But you've only asked a question about how to get a specific solution to work, so it's hard for us to decide what the "different and better solution" might be. (I do like trying to correct JMC when he is too harsh but in this case I really think he was being "firm", not "mean".
It's kind of like if I asked you how to make a screwdriver hurt less when I hit things with it. The right answer isn't to suggest wrapping the handle with tape or something soft. The right answer is to ask, "Well... why are you hitting things with a screwdriver?" That might lead me to reveal I'm trying to drive nails, and then you can rightfully suggest I use a hammer.
It doesn't really matter if the screwdriver's been working. A hammer is a better solution to the problem. Professionals should always be seeking the "best" solutions, lest their skillset stagnate.
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
-
Nov 29th, 2017, 11:58 AM
#16
Re: "conditional" dim type
I liked JMC's first answer, the best: We don't know enough to say what would work best, in this case.
Generics are great.....unless they only work with types A and B, and somebody offers up type C.
Overloads are great.....unless the situation is such that they aren't.
Late binding is great....but only when necessary, cause it's ALWAYS slower (you may not notice, though), can hide bugs, and can be painful to debug.
There's also a fourth option, at least, which is almost silly, but the OP left it open as a possibility: Take an extra argument, and use the one that is appropriate. That's bad....unless it is the best option. We simply don't know enough to say.....but we sure are happy to advise.
My usual boring signature: Nothing
-
Nov 29th, 2017, 02:11 PM
#17
Thread Starter
New Member
Re: "conditional" dim type
Hello Everybody - sorry for the delay, but i only have occasionally time to work on this.
Thanks everybody for their thoughts and ideas. I guess i have to provide a better example/explanation of what i am trying to do.
I have/build a program which runs calculations/analysis against number sets. These sets can be with 2 different characteristics (hence the 2 structures).
some of the calculations are exactly the same regardless of structure 1 or 2, therefore i am trying not to duplicate the coding and have 2 seperate Subs with the same code.
this is where the Subs needs to be flexible as to which structure it is receiving. I have tried to not specify the type for the variable, but as i have some, i think they are called Lambda functions, those didn't like that too much and errored.
below is a more detailed sample of what i am trying to do. i realy can't change anything other than the "FillGrid" or the button clicks as the structures are already used all over the app.
Code:
Public Structure myPair1
Dim Number1 As Integer
Dim Number2 As Integer
Dim PairCount As Integer
Private _Number_1 As Integer
Private _Number_2 As Integer
Private _p3 As Integer
Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
' TODO: Complete member initialization
If Number_1 < Number_2 Then
_Number_1 = Number_1
_Number_2 = Number_2
Else
_Number_1 = Number_2
_Number_2 = Number_1
End If
_p3 = p3
Number1 = _Number_1
Number2 = _Number_2
PairCount = _p3
End Sub
End Structure
Public Structure myPair2
Dim Number1 As Integer
Dim Number2 As Integer
Dim Number3 As Integer
Dim PairCount As Integer
Private _Number_1 As Integer
Private _Number_2 As Integer
Private _Number_3 As Integer
Private _p3 As Integer
Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
' TODO: Complete member initialization
If Number_1 < Number_2 Then
_Number_1 = Number_1
_Number_2 = Number_2
Else
_Number_1 = Number_2
_Number_2 = Number_1
End If
_p3 = p3
Number1 = _Number_1
Number2 = _Number_2
Number3 = _Number_3
PairCount = _p3
End Sub
End Structure
Private Sub btn_1_Click(sender As System.Object, e As System.EventArgs) Handles btn_1.Click
dim myPairs1 as new List(of myPair1)
myPair1.Number1 = 1
myPair1....
FillGrid(myPairs1)
End Sub
Private Sub btn_2_Click(sender As System.Object, e As System.EventArgs) Handles btn_2.Click
dim myPairs2 as new List(of myPair2)
myPair2.Number1 = 1
myPair2....
FillGrid(myPairs2)
End Sub
Public Sub FillGrid(ByRef TempmyPairs)
Dim myCash5Pairs
If Form1.AllGames.Item(myGame).NumbersToPick = 5 Then
myPairs = New List(Of myPair1)
Else
myPairs = New List(Of myPair2)
End If
myPairs = TempmyPairs
' '''
' sort the list so that we can hilghlight best and worst
myPairs.Sort(Function(p1, p2) p1.PairCount.CompareTo(p2.PairCount))
.....
end sub
-
Nov 29th, 2017, 02:24 PM
#18
Re: "conditional" dim type
Those are pretty large for structures, so you might consider making them classes.
You COULD use inheritance for this. It looks like myPair1 is a subset of myPair2, so you could have myPair2 inherit from myPair1. You'd then just pass in an argument of type myPair1, because any child can be implicitly cast to its base. In other words, if the argument was type myPair1, you could freely pass in an object of type myPair2, because myPair1 is a base of myPair2, so you don't even need to do any conversion.
Internally, if you had that inheritance relationship, then you could make a List(of myPair1), which could hold either myPair1 or myPair2. You can also use GetType to figure out which type you actually have, and if it is a myPair2, you could cast it to the proper type to get access to the members specific to myPair2. Alternatively, you could add a member to myPair1 that would just return True or False, or an integer, or something, to indicate whether it was a myPair1 or myPair2. That may be faster than the reflection that GetType would require....but quite likely not.
Another advantage of inheritance is that myPair2 would only need those members that are unique to that type. It would inherit the members from myPair1 that are either Protected or Public....well, it would really inherit ALL the members, but would only have access to those that are Protected or Public.
My usual boring signature: Nothing
-
Nov 29th, 2017, 02:46 PM
#19
Fanatic Member
Re: "conditional" dim type
for me the only thing i see is one structure is using an extra set of variables, and since your already using these structures throughout i would simply make another structure just like you have but use arrays instead.
It seems like in mypair1 your assigning the lowest value to number1 and the other value goes to nummber 2, but in mypair2 the number 3 is just number 3 no matter what the other values are? and you seem to be just repeating values?
Code:
Dim Number1 As Integer
Dim Number2 As Integer
Dim Number3 As Integer
Dim PairCount As Integer
Private _Number_1 As Integer
Private _Number_2 As Integer
Private _Number_3 As Integer
Private _p3 As Integer
seem very redundant....
the logic seems all the same and i would actually just replace both structures and replace them with another one that uses arrays and if needbe write some functions to return the values that you need from the current code you have......
if that is to much work then i would just write a third structure based on the other 2..
in any case this is how i may do it, have a look and see if this would work.
Code:
Public Structure myPair3
Dim Numbers() As Integer
Dim PairCount As Integer
Dim PairIndex as Integer
Sub New(PairIndex AS Integer, Number_1 As Integer, Number_2 As Integer, p3 As Integer, Optional Number_3 As Integer) 'Or use a Param Array here instead and count the entries
if pairindex = 1 then
redim Numbers(1)
If number_1 > Number_2 then
Numbers(0) = Number_1
Numbers(1) = Number_2
Else
etc etc....
End If
End Sub
End Structure
Yes!!!
Working from home is so much better than working in an office...
Nothing can beat the combined stress of getting your work done on time whilst
1. one toddler keeps pressing your AVR's power button
2. one baby keeps crying for milk
3. one child keeps running in and out of the house screaming and shouting
4. one wife keeps nagging you to stop playing on the pc and do some real work.. house chores
5. working at 1 O'clock in the morning because nobody is awake at that time
6. being grossly underpaid for all your hard work
-
Nov 29th, 2017, 03:03 PM
#20
Re: "conditional" dim type
I still don't get it. (And GBeats is confused by the same thing!)
Let's look at:
Code:
Public Structure myPair2
Dim Number1 As Integer
Dim Number2 As Integer
Dim Number3 As Integer
Dim PairCount As Integer
Private _Number_1 As Integer
Private _Number_2 As Integer
Private _Number_3 As Integer
Private _p3 As Integer
Sub New(Number_1 As Integer, Number_2 As Integer, p3 As Integer)
' TODO: Complete member initialization
If Number_1 < Number_2 Then
_Number_1 = Number_1
_Number_2 = Number_2
Else
_Number_1 = Number_2
_Number_2 = Number_1
End If
_p3 = p3
Number1 = _Number_1
Number2 = _Number_2
Number3 = _Number_3
PairCount = _p3
End Sub
End Structure
The only thing different in this structure from myPair1 is the Number3 field and _Number_3 field. neither of these are actually set. The constructor is identical to myPair1 so when you get to this line:
Code:
Number3 = _Number_3
That's not doing anything but setting a variable that's already 0 to be 0. Maybe this is some kind of error so let me step aside from it and illustrate how I'd handle what I think you might have.
My guess is you have data types with Number1, Number2, ..., NumberN. I'm not quite sure what PairCount is. If I had to design this type, here's what I would've done:
Code:
Public Class NumberSet
Public Property Numbers() As Integer
Public Property PairCount As Integer
Public Sub New(ByVal numbers As IEnumerable, ByVal pairCount As Integer)
Me.Numbers = numbers.ToArray()
Array.Sort(Me.Numbers)
Me.PairCount = pairCount
End Sub
End Class
Now FillGrid would look something like this:
Code:
Public Sub FillGrid(ByRef inputPairs As IEnumerable(Of NumberSet))
' Instead of ''' you should've showed us what you do here.
inputPairs = inputPairs.OrderBy(Function(p) p.PairCount)
End Sub
If the only difference between the two structures is "the number of integers", an array represents that concept perfectly.
I'm still suspicious if you weren't hiding most of your code I could come up with a much better solution. I'm still guessing at 80% of what you're trying to do. My guess is the hangup is FillGrid wants to create DataRow objects for a DataGridView, and you're not sure how to facilitate different numbers of field per structure. How warm am I?
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
-
Nov 29th, 2017, 03:04 PM
#21
Thread Starter
New Member
Re: "conditional" dim type
thanks for your replies.
GBeats :
interesting thought with the array , but:
- these structures are used all over the app and a variable using such a structure might be filled, tossed around, etc throughout and then being used in several functions down the road. the sample i created is strongly simplified.
- since i have some sorting, finding, and comparing calls against variable with those structures i found it easier to a structure architecture as i have indicated above. it allowed for certain actions which i was not able to do otherwise.
Shaggy Hiker:
- as mentioned to GBeats i really don't want to change the structures, as i would have to re-invent the wheel throughout the program.
- i used to have those as classes, because it gave me greater architect abilities. but i found that classes are limited in certain areas (i don't remember which problem i ran into back than), but structures worked better in my case. When i had to change it to structures i had to go through the entire app and adjusted coding - it was a pain!
-
Nov 29th, 2017, 03:14 PM
#22
Thread Starter
New Member
Re: "conditional" dim type
Sitten Spynne :
Yes, you are correct: i am "hiding" most of my code. although hiding is not entirely the correct word. i am just not able to post all of the some 8000 lines of code here.
And yes, the structures are much more complex then posted here and there are more similar structure than that one. my sample was a sample and a proof of concept.
as i mentioned these structures and the variable using them are used and "molded" throughout the entire app.
as in my other reply, i come back to saying before i change the architecture of the structure i rather have FillGrid twice.
since all the responses focus on changing the structures, i guess that's what i will have to do.
again, thanks everybody for your suggestions!
-
Nov 29th, 2017, 03:28 PM
#23
Thread Starter
New Member
Re: "conditional" dim type
Originally Posted by Goggy
Goggy :
Thanks for your reply.
I had not worked with overloading - i'll look into it.
upon 1st reads it seams it may be the answer - i have to find out how that exactly works and how to build this.
-
Nov 29th, 2017, 03:45 PM
#24
Re: "conditional" dim type
While I agree that changing something throughout an app can be a difficult trigger to pull, sometimes it is the right one.
My usual boring signature: Nothing
-
Nov 29th, 2017, 04:37 PM
#25
Re: "conditional" dim type
I understand but I'm not really sure I can really give a good answer while in the dark. I get that sometimes it's not possible/feasible/legal to post it all. This is a frustrating way our hands get tied.
The thing is, when it comes to architecture we tend to think in patterns and abstractions to a degree that a lot of people can't stomach. That's why when I saw your structures, the only thing I could see is "an array of Integer", it's a substitute for "a lot of fields".
The problem as you have it is making me think about how I think when I'm in a less strongly typed language like JavaScript. In modern languages, designers are experimenting with the idea of types having a "shape" defined by their members. If two types have the same or similar "shapes", they're interchangeable in these languages. The more functional ones prefer using "tuples" instead of types for this, and this concept has bled into C#.
When a language has those concepts, you can write code that does different things based on the "shape" of its input. "Number of members" is one of the things that can distinguish the "shape" of an object. So in C# it's possible to take a variety of Tuples and do different things based on their shape. VB does not have such sophisticated support for ValueTuple so it can't talk about the "shape" of types.
That's why I suggested changing the Structures to have an array of Integer rather than several Integer properties. In pre-2017 C# and all flavors of VB, that is the only way we can express the "shape" that says "I have a variable number of Integer values."
This answer is wrong. You should be using TableAdapter and Dictionaries instead.
-
Dec 5th, 2017, 04:12 PM
#26
Re: "conditional" dim type
I know I'm a little late to this party but I find it strange no one suggested using interfaces for this. Interfaces would solve this more elegantly. While you can shoehorn generics and inheritance to fit this, these solutions suffer from their weaknesses. Inheritance doesn't allow you to mix and match features in an elegant way:-
vbnet Code:
'
Public Class BaseType
Property NumberType1 As Integer
Property NumberType2 As Integer
End Class
Public Class TypeA
Inherits BaseType
Property NumberType3 As Integer
Property NumberType4 As Integer
End Class
Public Class TypeB
Inherits BaseType
Property NumberType5 As Integer
Property NumberType6 As Integer
End Class
Public Class TypeC
Inherits BaseType
Property NumberType7 As Integer
Property NumberType8 As Integer
Property NumberType9 As Integer
End Class
Public Class TypeAB
Inherits BaseType
Property NumberType3 As Integer
Property NumberType4 As Integer
Property NumberType5 As Integer
Property NumberType6 As Integer
End Class
Public Class TypeAC
Inherits BaseType
Property NumberType3 As Integer
Property NumberType4 As Integer
Property NumberType7 As Integer
Property NumberType8 As Integer
Property NumberType9 As Integer
End Class
Pay particular attention to TypeAB and TypeAC. We wanted a combination two different combinations of the types previously defined. The problem is that these combo types are two different types, and we would have to write extra code for these extra types. But we shouldn't have to do that since semantically they are a combination of previous types. We should be able to let the TypeA code handle the TypeA part of TypeAB and the TypeB code handle the TypeB part of TypeAB. The same logic should apply to TypeAC.
vbnet Code:
'
Public Class MyProcessingMethods
Public Shared Sub Process(ByVal type As BaseType)
DoWork(type.NumberType1)
DoWork(type.NumberType2)
If TypeOf type Is TypeA Then
With DirectCast(type, TypeA)
DoWork(.NumberType3)
DoWork(.NumberType4)
End With
End If
If TypeOf type Is TypeB Then
With DirectCast(type, TypeB)
DoWork(.NumberType5)
DoWork(.NumberType6)
End With
End If
If TypeOf type Is TypeC Then
With DirectCast(type, TypeC)
DoWork(.NumberType7)
DoWork(.NumberType8)
DoWork(.NumberType9)
End With
End If
If TypeOf type Is TypeAB Then
With DirectCast(type, TypeAB)
DoWork(.NumberType3)
DoWork(.NumberType4)
DoWork(.NumberType5)
DoWork(.NumberType6)
End With
End If
If TypeOf type Is TypeAC Then
'.......You get the point
End If
End Sub
Private Shared Sub DoWork(ByVal v As Integer)
End Sub
End Class
The problem with the above is that we are repeating code when we don't have to. We are writing code to handle TypeA three times, once for TypeA, once for TypeAB and once for TypeAC. We should only have to do this once. Now you could reduce this by having TypeAB inherit from TypeA instead of the base type and do something similar for TypeAC but you're still going to be repeating code. For TypeAB, you'd still be repeating for the TypeB portion of TypeAB.
Interfaces solves this quite nicely:-
vbnet Code:
'
Public Interface ICommon
Property NumberType1 As Integer
Property NumberType2 As Integer
End Interface
Public Interface ISetA
Property NumberType3 As Integer
Property NumberType4 As Integer
End Interface
Public Interface ISetB
Property NumberType5 As Integer
Property NumberType6 As Integer
End Interface
Public Interface ISetC
Property NumberType7 As Integer
Property NumberType8 As Integer
Property NumberType9 As Integer
End Interface
Now you can mix and match as you please. You could combine A and B or A and C or A, B and C but you only have to write code for 3 interfaces. Don't matter how many combinations you create, you only have to test for 3 interfaces:-
vbnet Code:
'
Public Class MyProcessingMethods
Public Shared Sub Process(ByVal type As ICommon)
DoWork(type.NumberType1)
DoWork(type.NumberType2)
If TypeOf type Is ISetA Then
With DirectCast(type, ISetA)
DoWork(.NumberType3)
DoWork(.NumberType4)
End With
End If
If TypeOf type Is ISetB Then
With DirectCast(type, ISetB)
DoWork(.NumberType5)
DoWork(.NumberType6)
End With
End If
If TypeOf type Is ISetC Then
With DirectCast(type, ISetC)
DoWork(.NumberType7)
DoWork(.NumberType8)
DoWork(.NumberType9)
End With
End If
End Sub
Private Shared Sub DoWork(ByVal v As Integer)
End Sub
End Class
In the future OP, you should think about interfaces when you come up against a problem like this. It will save you a lot of headaches.
-
Dec 5th, 2017, 04:46 PM
#27
Re: "conditional" dim type
Yeah, interfaces can solve a whole lot of issues. I don't think they get enough coverage.
My usual boring signature: Nothing
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|