Properties VS Data members

Is it better to make all exposed things Properties as opposed to public data members?
LVL 1
daniel_bighamAsked:
Who is Participating?
 
malharoneConnect With a Mentor Commented:
it really depends on the application, and the usage of that class.

'-- vb syntax
case 1:
public cust as Customer
PRO: easy .. less typing
CON: you don't have any control over this object


case 2:
private cust_ as Customer
public property cust as customer
  get
     return cust_
  end get
  set (byval value as customer)
     cust_=value
  end set
end property
PRO: option for readonly/writeonly
CON: setting object is ONLY by value

case 3:
  private cust_ as customer
  public function getCustomer() as customer
       return cust_
  end function
  public function setCustomer(byref c_ as customer)
     cust_=c_
  end function
PRO: full control over get/set, and byref/byval
CON: too much typing
0
 
daniel_bighamAuthor Commented:
I understand these pros and cons.

Maybe I should be more specific. If you don't need any special control, is there any reason to use Properties over Public Members? It seems a bit inconsistent to have some of your members exposed as Properties and some as Public Members. For instance, the .NET framework seems to expose EVERYTHING as properties.
0
 
malharoneCommented:
what do you mean by "the .NET framework seems to expose EVERYTHING as properties."

it depends what class you're dealing with
becuase property statements and public variables are simply "properties", but visually they're not distinguished

but if you dont want any control, or you know that no one's is going to exploit the public members, then go head.
you also want to use "public" members, if you want the objects to be set by REF and not by value.
0
 
daniel_bighamAuthor Commented:
What I mean by the framework exposing everything as properties... if you examine the .NET class library, for instance the Form class, there are no public data members exposed directly. They are all exposed as properties. This motivated the question: If Microsoft never exposes public data members (always wraps them as properties) for their class library, is that evidence that it is best practice to always wrap public data members by properties?

Your answer seems to be "No", although I'm not sure you understood my motivation for asking the question (That MS seems to).
0
 
malharoneCommented:
not really ... it's just the editor (i think) is incapable of differentiating from an object being exposed directly through a "Public" declaration or through a public property declaration.
if you look at the .length "property" of an (any) array, you'll see it as listed only as a readonly property.
but there are some properties that must be declared using "public blahObject as BlahClass" as opposed to "public property blahObject as BlahClass ... get .. set"
Microsoft may have chosen not to use "public obj as class" way may be because it's not as safe as the set method of a property statement -- which forces param passing byval).
i've nt come across an example where it's not a propery statement, since MS lists class members in the a) Constructors; b) public properties; c) public methods; d) public events; e) protected properties; f) protected methods;

they should've broken properties into
i) public properties
ii) public data members
0
All Courses

From novice to tech pro — start learning today.