Last post Aug 21, 2009 03:51 PM by atconway
Aug 13, 2009 03:02 PM|atconway|LINK
I have the following code:
Public Class MyColorsClass
Public Sub New()
Public Sub New(ColorID As Integer)
Me.ColorType = ColorID
Public Enum ColorTypes
Red = 1
Blue = 2
Black = 3
Orange = 4
Purple = 5
Private mColorTypes As ColorTypes
Public Property ColorType() As ColorTypes
Set(ByVal value As ColorTypes)
mColorTypes = value
Public ReadOnly Property IsColorCool() As Boolean
Select Case Me.ColorType
Now I have a very specific question on the code above (I say this because a lot of times people make unrelated comments which do not help, so please stick on topic
). Notice there are (2) class constructors. If I call the one with the parameter, then by the time I access the
'IsColorCool' property, the return WILL be valid, as the ColorType was already defined (in the constructor).
However, if the empty constructor was called to instatiate this class then the colortype is not yet set. Therefore, if one accesses the 'IsColorCool' property it will always return 'False'. Now for the sake of this example, I
must keep the empty constructor as part of the class.
Now I could add some code in the 'IsPropertyCool' to check and see if a ColorType has been defined, and throw an exception if it has not been set, but I don't really want to do that. I also could always move the logic OUT of the property and into a method
on the class called 'DefineIfColorIsCool' or something, and make the owness on the caller to make sure the method was called if they want to use the property 'IsColorCool'
My question is this: is doing the code the way I have breaking some sort of design principal to have that property be dependent on another property, even though its possible that other property has not been set?
Aug 20, 2009 11:37 AM|atconway|LINK
Did anyone have any thoughts or insight into my question?
Aug 20, 2009 11:49 AM|NihirPorecha|LINK
IMHO, as far as the property serve its purpose there is nothing wrong in that kind of design.
As the purpose of your IsColorCool property is to let the user know whether the color they have set is blue(or which ever colors you prefer as cool).
Considering that user has not set any color at all. That means, we can say that user has not set any of the cool colors(unless and until you decide to have any of the cool color as your default color).
So, considering it the property returning false serves its purpose. Isn't it?
Aug 21, 2009 12:29 PM|atconway|LINK
Yes that's true; if a color is not set then it is valid to say that returning 'False' is correct because the color is not cool, because one has not been set. I guess I was wondering about the fact that is 'IsColorCool' retunring 'False' because the color
is truely not cool, or because no color was set at all.
Technically I guess both are valid; would it be appropriate to test within that property if a color was set, and if one has not then an exception is thrown?
Aug 21, 2009 03:45 PM|Mark DotNet Evans|LINK
I would say NOT to thrown an exception. The key to this is what are you implying by the name of the property. Your property is asking the question IsColorCool and regardless of whether you have set the color or not, it is only cool if the color is blue
so I would never expect an exception to be thrown and I would never code to expect one.
Aug 21, 2009 03:51 PM|atconway|LINK
Great, thanks everyone for the insight! :D