CODEWITHSUNDEEP
vb.netoop
Curtis
Curtis

Reputation: 103348

Is there any advantage of using Property's in this class?

I have the following class:

Class MyClass

    Property MyInteger as Integer
        Set(ByVal value as Integer)
            _MyInteger = value
        End Set
        Get
            Return _MyInteger
        End Get
    End Property
    Private _MyInteger as Integer

End Class

As I'm not using any validation etc in my Property, is there any advantage of using a Property in this case, or would it be neater to use:

Class MyClass

    Public MyInteger as Integer

End Class

Upvotes: 2

Views: 315

Answers (4)

Miro J.
Miro J.

Reputation: 4964

I think all answers so far are right as long as they talk about the newest VS.NET versions that support automatic properties. At the same time, I would have to disagree with the recommendation to ALWAYS do properties. Imagine a scenario when you have a class with 100+ members that do not require any validation. From a business stand point, you will have to invest a lot of time in creating both - members and property encapsulation - only because there is a chance that in the future you MAY need them.

I would suggest a bit of a different rule: Always follow the Property rule when the consumer of your class / DLL is external so they do not brake the compatibility and you don't force them to recompile their code. Alternatively, If you know that the class is only internal to the project and you will save a lot of time by not doing the encapsulation, you can choose the business approach and save time. At the end of the day, we are always late in our projects and one of our main goals is to make money (maybe not for ourselves but for someone else that hired us), right?

Upvotes: 0

Mark Booth
Mark Booth

Reputation: 7944

Generally speaking, public member variables in classes are frowned upon, it breaks the encapsulation tenet of object oriented programming.

Such rules are not there for the sake of it, but for good reason. By making the variable public you are making the code more difficult to maintain and restricting what you can do with it later.

Although you may not want to do validation on the value now, what happens if you need to add it later? What about if you need to make it a read only value, where the class itself can change the value, but clients cannot?

Where this causes the biggest problem is if you are implementing a library. If you supply version 1 of the library with a public member and then in the second version of the library, have to convert it to a property, you will have to recompile every assembly which uses that library.

It is for this reason (amongst others) that VB.net 10 added auto properties:

Class MyClass
    Public Property MyInteger as Integer
End Class

Now you can default to creating auto-properties for things which you would have made public member variables, then if you later need to upgrade to a full property, so can do so without changing the interface.

Upvotes: 3

Bueller
Bueller

Reputation: 2344

Well, if you want to violate encapsulation (a basic tennat of OOP) you could do it the other way. You should never give direct access to members of a class to the outside world.

Upvotes: 0

ColWhi
ColWhi

Reputation: 1077

It depends on whether you want to use encapsulation and have the class "control" the value or you are happy for the number to be manipulated by "external forces". If the former, then I suggest you have a struct not a class.

Do you want to expose the internals of your class to the outside world?

Upvotes: 0

Related Questions