OOP question about properties & methods

[Guest]

Lets consider a class called Currency. This class must be the responsible for
taking care of all calculations over currency exchanges, in such a way that I
pass values in Euros and it returns the converted value in Dollar for
example...
Well, I might do this in 2 ways, as below:

1) I create a method like this:

double ConvertValue (double OriginalValue) {
// here I compute the value
return ComputedValue;
}


2) I create the method like this:

bool ConvertValue (double OriginalValue) {
// here I load private attribute ConvertedValue

ConvertedValue = ComputedValue

return OK;
}


In the first case I returned value in the method itself, in second case I
loaded the value in a private attribute. In second case the client method
would have to execute ConvertValue and then ask for property value. In first
case, the returned value would come in the method return itself....

What is the best approach? Are there special situations in which we should
use one or another??

 

[Jon Skeet [C# MVP]]

Lets consider a class called Currency. This class must be the responsible for
taking care of all calculations over currency exchanges, in such a way that I
pass values in Euros and it returns the converted value in Dollar for
example...
Well, I might do this in 2 ways, as below:

In the first case I returned value in the method itself, in second case I
loaded the value in a private attribute. In second case the client method
would have to execute ConvertValue and then ask for property value. In first
case, the returned value would come in the method return itself....

What is the best approach? Are there special situations in which we should
use one or another??

The first approach is definitely better. It means:

1) The caller only has to do one thing in order to do what they want -
get the converted value.

2) If you use exceptions to indicate unexpected failures, the caller
doesn't need to do anything in order to have the "safe" behaviour of
aborting as soon as an error occurs

3) If the operation *does* fail (and an exception is thrown) the
exception can give far richer detail than a simple true/false could

 

[Guest]

So in which case would I use second approach?

The first approach is definitely better. It means:

1) The caller only has to do one thing in order to do what they want -
get the converted value.

2) If you use exceptions to indicate unexpected failures, the caller
doesn't need to do anything in order to have the "safe" behaviour of
aborting as soon as an error occurs

3) If the operation *does* fail (and an exception is thrown) the
exception can give far richer detail than a simple true/false could

 

[Jon Skeet [C# MVP]]

So in which case would I use second approach?

Where the answer genuinely isn't useful at this point - in other words,
pretty rarely. Alternatively, "the answer" may not be a meaningful
concept, if many parts of the state of the object change.

If you have a situation where you wish to indicate success/failure
without using an exception, by the way, you should usually use the same
pattern as Double.TryParse, with an output parameter.

 

[Barry Kelly]

Lets consider a class called Currency. This class must be the responsible for
taking care of all calculations over currency exchanges, in such a way that I
pass values in Euros and it returns the converted value in Dollar for
example...

Have you considered writing a struct and using operator overloads to get
this functionality, rather than holding values in 'double'? (Just an
idea.)

Also, doubles aren't suitable for money anyway, due to rounding issues -
you should at least use 'decimal' instead.

Well, I might do this in 2 ways, as below:

1) I create a method like this:

double ConvertValue (double OriginalValue) {
// here I compute the value
return ComputedValue;
}

This method doesn't require state, so it can be a static method, in
which case your class is simply a namespace for global functions.

2) I create the method like this:

bool ConvertValue (double OriginalValue) {
// here I load private attribute ConvertedValue

ConvertedValue = ComputedValue

return OK;
}

I don't understand this. You are changing a private attribute, but what
does the containing class represent? If it represents a currency-typed
value, then why isn't the argument of the containing class type?

Also, I think if you have a problem, you should throw an exception,
rather than using a boolean return value to indicate success or failure.
If failure is to be expected sometimes, then provide two versions,

What is the best approach? Are there special situations in which we should
use one or another??

If you create a type to represent a currency value - i.e. create some
Currency class or struct - then I recommend that you make it immutable
and add operator overloads. That way leads to minimal confusion,
especially in the case of structs, where mutable methods can often end
up mutating copies rather than the originals.

If you're going to create a bunch of functions, then it's up to you to
get your semantics right everywhere you're writing code that manipulates
currency values.

Personally, I'd think hard about writing a Currency struct that is
'typed' - it keeps a tag indicating which currency its value refers to.
That way you have a tool with which to detect currency errors, at
runtime at least. And I'd overload it so that it works in a similar way
to 'decimal' (System.Decimal) - i.e. I'd prevent doubles from being
valid currency values, and I'd require explicit typecasts in order for
it to be converted into a double.

-- Barry

 

[Guest]

Well, I thought of using second approach for the simple reason it might be
"more OOP", otherwise why would properties exist for situations where you are
not dealing with visual objetcs?
Besides, isnt kind of bad habit working with "ref parameters" ?

 

[Barry Kelly]

Well, I thought of using second approach for the simple reason it might be
"more OOP",

A 'more OOP' approach would be the Currency struct approach I suggest in
a parallel post.

Besides, isnt kind of bad habit working with "ref parameters" ?

It's the only way to return multiple values without an extra allocation.

-- Barry

 

[Jon Shemitz]

Bruce One threw the animals some meat:

Lets consider a class called Currency. This class must be the responsible for
taking care of all calculations over currency exchanges, in such a way that I
pass values in Euros and it returns the converted value in Dollar for
example...

double ConvertValue (double OriginalValue) {
// here I compute the value
return ComputedValue;
}

bool ConvertValue (double OriginalValue) {
// here I load private attribute ConvertedValue

ConvertedValue = ComputedValue

return OK;
}

What is the best approach? Are there special situations in which we should
use one or another??

There is more than one thing a Currency class might do. Your spec
focuses on conversions, like dollar to euro or euro to pound. In this
case, a suite of static methods is what you want.

You might also want a Currency class to represent a sort of
"globalized value" - a money data type that you can set as dollars and
read as pounds, or set as euros and read as rand, and so on. In this
case, you want read/write instance properties named things like
AsDollar or AsEuro. (You might want to account for transaction costs -
a larger factor on small transactions than on large transactions.)

One class can fill both roles. A separated Money instance might use
static methods of the ExchangeRates class for conversions, but many
..NET classes have static methods as well as instance methods and
instance properties. That is, a Currency class can have both static
methods and instance properties. You can have Currency instances that
represent values and Currency methods that manipulate values in just
the same way that the String class does.

 

[Guest]

I must say using properties is far more elegant then using static methods...
But 1 thing I see that really makes a dif, is that properties enable us to
use n times the value in its instance, without having to call the method
again (something like keeping its state).
The problem is that I havent found where to really use them. If properties
could be "replicated" using static methods returning values, then all my
business logic classes would be a set of static methods...
One thing I realized properties might be welcome is when we return more than
1 value in the same method. In this case, instead of using ref values, we
might load n properties and then retrieve them right afterwards...

What do you think?

 

[Cor Ligthert [MVP]]

Bruce,

I definitly would not make a class name Currency, the currencymanager it is
an important class that already exist to get the current rows in the
system.data namespace. I have seen that this currencymanager gives often
misunderstandings, but I would not make that more worse.

http://msdn.microsoft.com/library/d...stemwindowsformscurrencymanagerclasstopic.asp

Therefore I would name it at least LocalizedCurrency or something.

Than it is of couse easy to return in that class the needed localized value
based on the localized settings of the computer.

The currencysymbol and other things are already in this and related member.

http://msdn2.microsoft.com/en-us/library/system.globalization.regioninfo.currencysymbol.aspx

I hope this helps,

Cor

 

[Guest]

Well Cor,

Thank you for the information on currency class/methods, I will take a look
at it...
But the example I put there was only to expose my concern on how I should
proceed when using properties (more elegant) vs returning values directly in
method return.
AFAIK, one big difference is that properties enable us to
use n times the value in its instance, without having to call the method
again (something like keeping its state).
Besides, properties might be welcome when we return more than
1 value in the same method. In this case, instead of using ref values, we
might load n properties and then retrieve them right afterwards...

Some fellows in this post have helped me posting that this True/False return
is not good, it should be replaced by exception control. That gives me even
less argument to choose the property way in cases I return just 1 value...

However I cant figure out those strict situations where I should choose one
or another...

 

[Barry Kelly]

But the example I put there was only to expose my concern on how I should
proceed when using properties (more elegant) vs returning values directly in
method return.

You should use properties when they are:

1) Logically attributes of the class, i.e. similar to fields
2) Cheap to calculate and return
3) If reading doesn't modify the observable state of the class
4) If writeable, then writing and subsequently reading gives the same
value (i.e. { a.Prop = 42; Debug.Assert(a.Prop == 42); }), unless
writing the property throws an exception because of a problem with the
value.
5) No arguments are required to calculate the return value

When using properties that take arguments (i.e. 'public int this[int
index] { get; set; }'), you should restrict them to things like lists
and dictionaries, things that are usually collections and indexed by key
or index.

-- Barry

 

[Guest]

Kelly,

Could your explain better points 3 and 4?

But the example I put there was only to expose my concern on how I should
proceed when using properties (more elegant) vs returning values directly in
method return.

You should use properties when they are:

1) Logically attributes of the class, i.e. similar to fields
2) Cheap to calculate and return
3) If reading doesn't modify the observable state of the class
4) If writeable, then writing and subsequently reading gives the same
value (i.e. { a.Prop = 42; Debug.Assert(a.Prop == 42); }), unless
writing the property throws an exception because of a problem with the
value.
5) No arguments are required to calculate the return value

When using properties that take arguments (i.e. 'public int this[int
index] { get; set; }'), you should restrict them to things like lists
and dictionaries, things that are usually collections and indexed by key
or index.

-- Barry

 

[Cor Ligthert [MVP]]

Bruce,

I would forever choose for a property if possible (in connection to my
previous reply) all was it alone that those are bindable, showable in a
property grid and serializable. Beside that do *I* find the text showed in
intellisence mostly standard better to understand from those.

When you want a direct answer, I never would take your method 2. It is only
confusing especially if the method is longer.

Cor

 

[Guest]

Cor,
So if you dont like executing a void method and then calling for the
property return, what would the best approach?
My great fear about using properties, instead of returning in method return
itself is that client code is unaware of what properties exaclty he should
reference to get the values he wants...

 

[Cor Ligthert [MVP]]

Bruce,

Using intelisense is the simplest method to tell the client all he wants to
know, it can be showed in the propertygrid and while selecting it in
intelisence by the comments.

http://msdn2.microsoft.com/en-us/library/z04awywx.aspx

Cor

 

[Barry Kelly]

Kelly,

My name is Barry!

Could your explain better points 3 and 4?

Just reading a property shouldn't change the property. For example:

Button b = new Button();
// ...
string text = b.Text;

This action (reading b.Text, which is a property) shouldn't change the
property. Another example:

IEnumerator x = new List().GetEnumerator();
bool b = x.MoveNext();

This action, MoveNext(), changes the enumerator - it moves it forward
one. Therefore it shouldn't be a property, it should be a method (which
it is).

When there is a property, people expect this:

b.Name = "foo";
if (b.Name != "foo")
throw new Exception("Something went wrong!");

If this code would throw an exception for your property, then it
shouldn't be a property - it should be a method.

This only matters if the property is writeable - that is, it has a 'set'
method.

-- Barry

 

[Guest]

Barry, sorry for misusing your name.
I think I quite understood your points, I will try to fit our cases in one
of these situations.

Thanks!