Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 666
  • Last Modified:

shared properties vs shared instance variables

If I have a class

public myClass {

    private shared m_intCnt as integer

   public shared property Count as integer
      get
            return(m_intCnt)
      end get
       set(byVal value as integer)
            m_intCnt = value
       end set
     end Property
end class


Is the above the same as if I just did this and didn't use a property at all?

public shared Count as integer

I'm trying to create a variable that can used across multiple threads.
0
rutledgj
Asked:
rutledgj
2 Solutions
 
käµfm³d 👽Commented:
There is no such thing as a "shared instance variable". If a variable is shared, it is a class-level variable and can be used by any instance of the class.
0
 
rutledgjAuthor Commented:
I can do either of the above in a class. The question is what is the difference?
0
 
wdosanjosCommented:
As a best practice, all fields should be private to the class.  So, you should favor a shared property over a shared field.  (http://msdn.microsoft.com/en-us/library/ms229057.aspx)

Below is a shorter version of the code you posted, which uses auto-implemented properties (http://msdn.microsoft.com/en-us/library/dd293589.aspx)

public myClass

   public shared property Count as integer

end class

Open in new window


I hope this helps.

0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
käµfm³d 👽Commented:
Well, in VB you can't have a property without a backing variable to hold data (unlike C#'s automatic properties which create the backing variable for you). Because you defined the property as Shared, so too must the variable it accesses. Shared members don't have access to instance members.

This is not to say you can't have a shared variable by itself (i.e. with no attached property). A shared variable can exist on its own. You would access it the same way you would a property; you would just be working with the variable directly. Properties in .NET are just fancy ways of using getter and setter methods. In reality, the runtime creates hidden getter and setter methods for any property you create. With this in mind, you should be able to understand why the backing variable is needed.

The concept of "shared" is just like it sounds--this member is accessible to all instances of the class--and some other things too. Whether you use a property (with a backing variable) or a variable alone is a question of design choice. OO best practices call for data hiding, and so having the property with a backing variable would be the preferred method.
0
 
käµfm³d 👽Commented:
@wdosanjos

Such a concept only exists in .NET 4.0. Pre-4.0 did not have automatic properties (C# did/does though).
0
 
käµfm³d 👽Commented:
P.S.

I wasn't aware 4.0 had introduced the concept, so that is the reason for the discrepancy in my two statements above.
0
 
Mike TomlinsonMiddle School Assistant TeacherCommented:
What's the difference?...with a PROPERTY you have the ability to enforce rules upon it.  If the variable is simply a public member than any value can be assigned to it.  Whether this matters is completely dependent on the project in question...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now