GivenRandy
asked on
Property or Method -- Which is Which
We have created many controls in the past, but recently we created a new ActiveX DLL and are having "religious" debates on whether some things are Properties or Methods. Our DLL has a collection of datapoints in it. It also keeps track of an external reference clock, among other things. The following are only a few examples. For each of the following, would it be a Property or a Method:
1) PointIndex(Name): PointIndex() is passed a name and returns an index.
2) AllNames(): returns a list of all the names in the collection.
3) PointCount(): returns the number of points in the collection.
4) SubscribePoint(Name): adds name to list so that the named point is constantly monitored.
5) PointValue(Name): reads the value of a named point.
6) WritePointValue(Name, Value): writes the value of a named point.
7) ReadPointValue(Name): reads the value of a named point.
8) Date(): reads or writes the date.
There may be multiple sets of points awarded, depending on the feedback.
1) PointIndex(Name): PointIndex() is passed a name and returns an index.
2) AllNames(): returns a list of all the names in the collection.
3) PointCount(): returns the number of points in the collection.
4) SubscribePoint(Name): adds name to list so that the named point is constantly monitored.
5) PointValue(Name): reads the value of a named point.
6) WritePointValue(Name, Value): writes the value of a named point.
7) ReadPointValue(Name): reads the value of a named point.
8) Date(): reads or writes the date.
There may be multiple sets of points awarded, depending on the feedback.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SubscribePoint(Me)
Just to clarify why 5,6 and 7 are the same property
Public Property Get PointValue(Byval strName as String) as String
Public Property Let PointValue(Byval strName as String, strValue as String)
5) PointValue(Name): Property Get PointValue
6) WritePointValue(Name, Value): Property Let PointValue
7) ReadPointValue(Name): Property Get PointValue
Public Property Get PointValue(Byval strName as String) as String
Public Property Let PointValue(Byval strName as String, strValue as String)
5) PointValue(Name): Property Get PointValue
6) WritePointValue(Name, Value): Property Let PointValue
7) ReadPointValue(Name): Property Get PointValue
John,
I can agree with you in principle and you could argue that in fact 5 and 7 are indeed duplicates. 6 could be either a method or a property and perhaps on reflection is indeed that rather than a method.
I can agree with you in principle and you could argue that in fact 5 and 7 are indeed duplicates. 6 could be either a method or a property and perhaps on reflection is indeed that rather than a method.
ASKER
>I would categorise a method as routine which takes zero
>or more arguments and executes one or more related
>actions as a result. Optionally this may return a value
>indicating the result of the action(s).
That is very close to the definition that I use. Some say that any time you pass an argument (at all), it is required (!) to be a method. For example, #5 would have to be a Method under that definition:
lngSomeResult = X.Value(SomeName)
However, it gets interesting, as even your breakdown illustrates. Let's suppose we are writing the value. Here are two cases, using the above:
#5: X.PointValue(SomeName) = 23.5
#6: X.WritePointValue SomeName, 23.5
You would make #5 a Property while #6 would be a Method. I tend to agree with you. I think it is somewhat silly to automatically list something as a Method simply because it has arguments -- a method implies "doing something".
>or more arguments and executes one or more related
>actions as a result. Optionally this may return a value
>indicating the result of the action(s).
That is very close to the definition that I use. Some say that any time you pass an argument (at all), it is required (!) to be a method. For example, #5 would have to be a Method under that definition:
lngSomeResult = X.Value(SomeName)
However, it gets interesting, as even your breakdown illustrates. Let's suppose we are writing the value. Here are two cases, using the above:
#5: X.PointValue(SomeName) = 23.5
#6: X.WritePointValue SomeName, 23.5
You would make #5 a Property while #6 would be a Method. I tend to agree with you. I think it is somewhat silly to automatically list something as a Method simply because it has arguments -- a method implies "doing something".
ASKER
Er (dang, cannot edit comment), #6 is more like a property and probably should be changed to look like a property (e.g., use "PointValue" as read/write instead of having "WritePointValue").
ASKER
What about a case where the function may return an array of values. For example, requesting a name will return a 10-element array of values -- requesting (ByVal) SomeName returns (via ByRef) the array into SomeArray:
X.ReadPoint(SomeName, SomeArray)
Is that still a Property or has it morphed into a Method?
X.ReadPoint(SomeName, SomeArray)
Is that still a Property or has it morphed into a Method?
I'd still say a property, on the grounds that SomeName and SomeArray map to variables of your class. A method should invloke some action e.g. paint, draw create, destroy, load, unload. A property on the other hand should map to states and state data within the class. Thus changing a property value should alter te state or state data of your class. The obvious exception is a method that manipulates numerous state data values as in read/write properties.
According to the latest Java standards, which seems to be what MS is paralleling with .Net, there really are no properties anymore.
All "properties" are really just public variables, and exposing variables seems to cause too many problems. Rather, all variables are simply private areas of the object that can be set/retrieved via methods.
Ex.
Rather than:
property myValue
you get two methods:
sub setMyValue(Value as Object)
and
function getMyValue() as Object
That said, the general rule is that if the thing is a storage area, it's a property; if it's an action, it's a method.
By looking at your names, 4 has an action built into the names and is therefore probably a method; 5 to 7 may have actions attached to them so they MAY be methods; the others seem to be storage areas and are essentially properties. Also, based on the description, #8 may be a method, but based on the name it may be a property.
All "properties" are really just public variables, and exposing variables seems to cause too many problems. Rather, all variables are simply private areas of the object that can be set/retrieved via methods.
Ex.
Rather than:
property myValue
you get two methods:
sub setMyValue(Value as Object)
and
function getMyValue() as Object
That said, the general rule is that if the thing is a storage area, it's a property; if it's an action, it's a method.
By looking at your names, 4 has an action built into the names and is therefore probably a method; 5 to 7 may have actions attached to them so they MAY be methods; the others seem to be storage areas and are essentially properties. Also, based on the description, #8 may be a method, but based on the name it may be a property.
ASKER
Thanks!
I also left points for JohnMcCann:
https://www.experts-exchange.com/questions/20557347/Points-for-JohnMcCann.html
I also left points for rspahitz:
https://www.experts-exchange.com/questions/20557349/Points-for-rspahitz.html
I also left points for JohnMcCann:
https://www.experts-exchange.com/questions/20557347/Points-for-JohnMcCann.html
I also left points for rspahitz:
https://www.experts-exchange.com/questions/20557349/Points-for-rspahitz.html
1) PointIndex(Name): Property
2) AllNames(): Property
3) PointCount(): Property
4) SubscribePoint(Name): Method
5, 6 and 7 all the same property
5) PointValue(Name):
6) WritePointValue(Name, Value):
7) ReadPointValue(Name):
8) Date(): Property