I recall being told by a professor the following is bad practice. But it makes stepping through code a lot less tedious. I'm just solicting comments on pros and cons:
Friend Class MyClass
Private isEmpty As Boolean
Public Property IsEmpty() As Boolean
Get
Return isEmpty
End Get
Set(ByVal Value As Integer)
isEmpty = value
End Set
End Property
Public Sub MyMethod()
''//Is this more correct:
If Me.IsEmpty() Then
''//Do something.
End If
''//Is this bad practice?:
If isEmpty Then
''//Do something.
End If
End Sub
End Class
If you have set up a property to access the private member variable "isEmpty", than yes, I would use the property inside of the class itself unless there is a darn good reason for not doing so.
The reason being that you may at a later point in time need to do more work when the property is set (or possibly when retrieved), and then you would likely have to find all the references to the private member variable in your class and change them to access the property instead.
To add to Ed's answer, some IDE's allow you to set a flag saying you do not want to dive into property getter/setters like this. I don't know about VB but C#/VS2008 will do this. So that takes 'stepping thru the code' convenience out of the equation in deciding what is the right thing to do.
It really gets down it instinct and experience as a developer. If you're super positive you'll never need to do any processing on that property, then I say access it directly. Otherwise write the wrapper, it doesn't really hurt.
Although, it has never been that big a deal to add it later either. I wouldn't get too religious about either method.
Related
I am bit confused over the need to use GET & SET methods in VB.net. I want to discuss two cases in this connection: firstly when we declare the property as PUBLIC and next when we declare the property as PRIVATE.
What is I find is when I define a property as public I can directly set and access the values of that property without using the GET/SET methods --- quite simple: See below
Module Program
Sub Main()
Dim t As New test()
t.name = "Roy" 'Label 1
Console.WriteLine("t.name = {0}", t.name)
Console.ReadLine()
End Sub
End Module
Class test
Public Property name() As String
End Class
When I declare that same property as private, as shown below, I can still set and access the value of private property by simply using a constructor and a public subroutine. See below:
Module Program
Sub Main()
Dim t As New test()
t.printValue()
Console.ReadLine()
End Sub
End Module
Class test
Private Property Name() As String
Sub New()
Name = "Roy" 'Label 2
End Sub
Public Sub printValue()
Console.WriteLine("Value stored in NAME is: {0}", Name)
End Sub
End Class
So my question is why at all do we need to use the GET/SET methods? I understand that whenever an assignment happens to a property the SET method is implicitly called...but can you please help me understand cases where we MUST explicitly use the GET/SET methods? Or it is that using GET/SET is more of a choice? Validation is one thing that can be added easily at a later stage if one uses GET/SET but then is that the only reason? PLs give your views.
Also, I came across the following two related questions in stackoverflow (for different languages though): Links below:
Why to use getter and setter methods to set class properties?
Why use getters and setters/accessors?
But i could not understand most of the reasons justifying the usage of the GET/SET methods. For example if we dont use the GET/SET method then we are exposing the property to the outside world - meaning it can be directly accessed from outside the class. But then this is true only for PUBLIC properties as PRIVATE properties cannot be directly accessed from outside the class. Similarly in the second link the author mentions the following as a reason to use GET/SET: Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages. What exactly does this mean --- any simple real life example?
A property is a wrapper around a field, i.e., a class or struct variable. It provides a getter and/or a setter method to access this variable. (You can also have a read-only property returning the result of a simple evaluation not bound to a single field.)
The getters and setters are implicitly called when reading from, respectively writing to properties.
So, the question is not whether to use getters and setters or not, but whether to access fields directly or via a property.
You can declare a property like this, by declaring a field and writing the getter and setter explicitly.
Private _prop1 As String ' Backing field
Public Property Prop1() As String
Get
Return _prop1
End Get
Set(ByVal value As String)
_prop1 = value
End Set
End Property
or use an Auto-Implemented Property
Public Property Prop1 As String
Both declarations are equivalent. The auto-implemented property implicitly declares a backing field and implements the getter and the setter accordingly.
It can make sense to declare a property as private when you use it only inside the class where it is declared. This still provides the advantages described in the links you provided because this property still hides the details of accessing a field, does validations, etc.; however, it does not forbid the direct access to the backing field inside the class. So, you need to be more disciplined with private properties.
What does a property mean for debugging? You can easily set a breakpoint inside a getter or setter to detect accesses to a property. You cannot set a breakpoint on a field because a field is never executed. It is just a declaration.
You can also add a System.Diagnostics.Debug.Writeline("=====> test") (writes to the Output window) or do some logging in getters and setters.
See also: Tutorial: Learn to debug Visual Basic code using Visual Studio
When using Windows Forms Data Binding or WPF Data Binding properties are required. They also allow change notification.
Dynamically Calculated Values
I didn't read those links, but one reason you might want to implement your own getters & setters is that you may want to return something that requires some type of calculation or manipulation. For example, suppose you have item Sale with properties RawPrice, SalesTax, and FinalPrice. However, you need/choose to dynamically calculate the final price (based on variable sales tax) each time. So you first set the RawPrice, and then query FinalPrice, which returns RawPrice + SalesTax, but SalesTax gets dynamically calculated based on some other property like country of origin etc.
Alternate View of Data
Another reason you might want to do this is to provide another view of the same core data. For example, if your data was an HTML page, perhaps one property returns the normal string value, while another "no-HTML" Property has a custom Getter that performs some regex to remove all HTML tags and return a plain-text variation. This allows you to keep all related code inside of a sub-assembly, rather than having your main program do various manipulations.
Code Portability
This can make your life a lot easier down the road because of code portability. Your code is now more easily re-usable in other projects, since all you need is that one assembly.
Private Variables vs Properties
If I'm doing something that calls for a class with properties like that, there's good chances it's going to have methods, too. Those methods are almost always going to require creating private variables that nothing outside the assembly needs to know about. However, in such cases, they are not going to be private properties but rather simply private variables. For example, instead of Private Property Name() As String, with its implied auto-implemented backer variables with getters & setters, I would instead just say Private Name() As String, which would be equivalent to Dim Name() As String. You can use variables, constants etc. within your class just as you normally would, and, by default, the rest of the world won't know anything about them.
I'm not sure why you'd use a private Property. Maybe there's a good reason; I just don't know what it is. Most of the time, a private variable is probably what you really want. If you think there's a reason that you actually need a Private Property, I'm curious to hear your thinking on it. (I'm always open to a new way of thinking!)
History
Auto-implemented properties were not present in Visual Basic .NET for many years. In the past, you had no choice but to use GET/SET. So it's a more recent development for VB.NET to be able to simply declare a property as you do in your first code example, and for the runtime to automatically generate the backer variables.
I want to make that variable can be assigned with null. But giving'?' seems doesn't work. Please help me find the way out. I'm new to this. Thanks
Public Class T3DObject
Public V(7) As Point
Public E(5) As Surface
End Class
Public Structure ListElmt3DObject
Public first As Elmt3DObject
End Structure
Public Class Elmt3DObject
Public child As ListElmt3DObject?
Public nxt As Elmt3DObject? 'this line is error
Public obj As T3DObject? 'this also error
End Class
Is there any other way? Please share. Thank you!!
This is the code that make error: NullReferenceException
Sub Process(ByRef E As Elmt3DObject)
While E.child IsNot Nothing Or E.nxt IsNot Nothing
'code
End While
End Sub
I know this is a VB.Net question, but to understand this it's helpful to understand some of how C# works, too. In C#, there is a concept of null. You can assign a null value to reference types (ie: VB.Net Class), but you cannot assign null to value types (ie: VB.Net Structure). Value type (Structure) variables always have a value of some kind.
Coming back to VB.Net, we have the Nothing keyword. However, Nothing is not a direct analog to C#'s null. It's closer to match to the C# default(T) expression. VB.Net allows you to assign Nothing to value types. It's just that when you do, you get the default value for the type.
The Nullable(Of T) type and associated language syntax features were designed to allow newer null semantics for value types. This doesn't apply to reference types, because reference types already have a concept of null.
While I'm here, I also see this:
Sub Process(ByRef E As Elmt3DObject)
Elmt3DObject is a reference type (Class). It's almost always a mistake to pass a reference type ByRef. You still want ByVal, because passing ByVal for Classes still passes the reference. It makes a copy of the reference, but it's still just a reference.
I want to use a counter for how many objects are created from a single class, so I thought that a Shared Property would be the way to go. But, VB doesn't like that and says, "Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class"
Private _Length As Integer = 0
Public Shared Property Length As Integer
Get
Return _Length
End Get
Set(value As Integer)
_Length = value
End Set
End Property
Is there a way to initialize a shared variable, in this case to zero, and have the Property still function correctly. I used the Java get/set methodology (getLength()/setLength())and that worked fine, but I'm sure that it would be frowned up by VBers.
Also, using two variables to get/set one that is actually used seems a bit redundant. I see why it is used in the VB methodology because of the recursion that happens, but it does look strange.
The backing field _Length must also be shared.
Private Shared _Length As Integer = 0
using two variables to get/set one that is actually used seems a bit
redundant.
You don't have two variables just one which is _Length, a property just manages how you can access that variable. Note that even auto implemented properties like this use a backing-field:
Public Property Length As Int32
You just don't see it since it will be generated for you.
It's really bugging me that the VS 2010 IDE isn't barking at me for trying to pass Nothing through a method parameter that takes an user-defined enum. Instead, it's passing 0 through to the method. c# would never allow this. Is there some module-level modifier I can add like option strict that will force the IDE to not allow these types of implicit conversions?
Sadly, no.
But you can assign values to your enumeration members while skipping 0 (or use a placeholder named None or something like that), and at least handle this case at run time.
Sub Main
MyMethod(Nothing) ' throws Exception
End Sub
Sub MyMethod(e as MyEnum)
If e = 0 Then
Throw New Exception
End If
End Sub
Enum MyEnum
a=1
b=2
c=3
End Enum
Nothing is the equivalent of default in the C# language. So no.
Reconsider your programming style, Nothing should be used very sparingly. Basically only in generic code, same place you'd use default in C#. You don't need it anywhere else, VB.NET doesn't insist on variable initialization like C# does. Any variable of a reference type gets initialized to Nothing automatically. Cringe-worthy to a C# programmer perhaps, but entirely idiomatic in VB.NET code.
I just installed Visual Studio 2010 Service pack (proposed on Windows Update), and I can see a new feature on the "intellisense" that means when I write a Function or Sub in VB.NET it doesn't auto-complete parameters with ByRef or ByVal...
1) Is there anyway that I can configure this option back to how it was before?
2) If I don't specify ByX, which one is used by default? (it seems like it is always ByRef)
It seems that this post covers your question:
http://msmvps.com/blogs/carlosq/archive/2011/03/15/vs-2010-sp1-changing-quot-byval-quot-vb-net-code-editor-experience.aspx
So no, there is no way to get the old behaviour. From now on ByVal is the default (what it was before) and it won't get added automatically to the method parameters.
In my opinion this is a good decision since it's making VB.NET a bit more consistent with C# and avoids unnecessary "noises"(it's already verbose enough).
Old behaviour:
Private Sub test(ByVal test As String)
End Sub
New behaviour
Private Sub test(test As String)
End Sub
Tim covered what you asked directly, but something else to keep in mind is that any reference type variable, like a user defined class even if passed by value will allow you to make changes to that instances properties etc that stay. It won't however allow you to change the entire object. Which may be why it seemed to you to be defaulting to by reference
Public Sub (Something As WhateverClass)
Something = New WhateverClass 'will result in no changes when outside this method
Something.Property1 = "Test" 'will result in an updated property when outside this method
End Sub
From MSDN:
The value of a reference type is a pointer to the data elsewhere in memory.
This means that when you pass a reference type by value,
the procedure code has a pointer to the underlying element's data,
even though it cannot access the underlying element itself. For
example, if the element is an array variable, the procedure code does
not have access to the variable itself, but it can access the array
members.
Beware when transferring routines to VBA, where the default is ByRef (see, e.g., "The Default Method Of Passing Parameters" at the bottom of this page, by the great Chip Pearson).
That can be messy.