OOP question about properties & methods

[Bruce One]

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]]

Bruce One <ra**@virtualso ftware.com.brwr ote:

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:

<snip>

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

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Bruce One]

So in which case would I use second approach?

"Jon Skeet [C# MVP]" wrote:

Bruce One <ra**@virtualso ftware.com.brwr ote:

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:

<snip>

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

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Bruce One <ra**@virtualso ftware.com.brwr ote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Barry Kelly]

Bruce One <ra**@virtualso ftware.com.brwr ote:

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,
similar to Int32.Try/Parse and Dictionary<TKey ,TValue>.TryGet Value etc.

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

--
http://barrkel.blogspot.com/

[Bruce One]

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" ?

"Jon Skeet [C# MVP]" wrote:

Bruce One <ra**@virtualso ftware.com.brwr ote:

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Barry Kelly]

Bruce One <ra**@virtualso ftware.com.brwr ote:

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

--
http://barrkel.blogspot.com/

[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.

--

..NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn In print, in stores.

[Bruce One]

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?

"Jon Shemitz" wrote:

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.

--

..NET 2.0 for Delphi Programmers www.midnightbeach.com/.net
Delphi skills make .NET easy to learn In print, in stores.

[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
misunderstandin gs, but I would not make that more worse.

http://msdn.microsoft.com/library/de...classtopic.asp

Therefore I would name it at least LocalizedCurren cy 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/lib...ncysymbol.aspx

I hope this helps,

Cor

"Bruce One" <ra**@virtualso ftware.com.brsc hreef in bericht
news:E0******** *************** ***********@mic rosoft.com...

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??