Anonymeuros
Unregistered
|
|
Interesting article...
I see in your money example, that you use a mutable Money class. Is this wise?
Code:
Money total = ...;
Money amount = ...;
total.increaseBy( amount );
I would certainly recommend that any implementation of a money concept is immutable. Or else how about a changeCurrency method? (rounding errors) or a divideBy method (again rounding errors)...
So instead I would strive for something like this instead
Code:
Money total = ...;
Money amount = ...;
total = total.add( amount );
And of cource support of multi-currencies, so that if total is 5 USD and amount is 1 EUR, then the total after addition should be [5 USD and 1 EUR], not something like 10 USD (ups, sorry - I'm ahead of time  )
Just my 2 cents (EUR, so that should a dime to you - ups, sorry - I'm ahead of time again )
|
Anonymous
Unregistered
|
|
About this "immutable".
Theoreticly nice, yes.
But how do you implemement it?
If you put in evrything as parameters in the constructor
it works fine if you have 1 to 3 attributes.
If you have more attributes your contructor turnes realy ugly.
Have you realy got any benifitts in real life of immutable
classes, i have not.
|
Anonymeuros
Unregistered
|
|
Quote:
About this "immutable".
Theoreticly nice, yes.
Indeed yes!
Quote:
But how do you implemement it?
Done that with exactly this... Money... Use it as much as I can , as it makes life so much easier. :-)
Think about testing for equality... and especially about testing for equality after serialization/deserialization...
Quote:
If you put in evrything as parameters in the constructor
it works fine if you have 1 to 3 attributes.
If you have more attributes your contructor turnes realy ugly.
Agree, but with the example... Money... I can actually just come up with two that make sense to me... currency and amount.
Quote:
Have you realy got any benifitts in real life of immutable
classes, i have not.
Well, I do... and so do you... you just don't know it yet! ;-)
|
Alexander
stranger
Reged: 09/05/03
Posts: 7
|
|
Whether one uses an immutable Money class or not is really a question of design. However, I would argue for a mutable one since, in my eyes at least, a Money class represents "an amount of money", which can grow or shrink over time. In this case, the methods "add(Money)" and "remove(Money) throws InsufficientFundsException" make sense.
Again, it's a question of design - there's no FINAL answer (i.e. Money need not be immutable)
|
Anonymeuros
Unregistered
|
|
Quote:
Whether one uses an immutable Money class or not is really a question of design. However, I would argue for a mutable one since, in my eyes at least, a Money class represents "an amount of money", which can grow or shrink over time. In this case, the methods "add(Money)" and "remove(Money) throws InsufficientFundsException" make sense.
Again, it's a question of design - there's no FINAL answer (i.e. Money need not be immutable)
Oh, my God?!?
So you woud like to have something like:
Code:
Money oneBuck = new Money("USD", 1);
Money fiveBucks = new Money("USD", 5);
oneBuck.remove(fiveBucks);
which would throw an InsufficientFundsException ?!?
Great design! Now I'll go and outsource you to India... ;-)
|
Alexander
stranger
Reged: 09/05/03
Posts: 7
|
|
A rather vague argument you are putting forward there, Anonymeuros. I would appreciate a more logical clarification than, "Ha ha! I am smarter than you".
To reiterate what I said previously - there are many ways to skin a cat. In the case of a Money class, one *can* use an immutable or mutable one; dependent on what the problem domain dictates. Hence, the example given by Allen Holub.
*Usually* a mutable Money class makes more sense to me, but that's me. That's how I use it. That doesn't mean it's *right* in every application. It depends...
|
Anonymeuros
Unregistered
|
|
Ok, sorry... I couldn't help myself... ;-)
Quote:
...in my eyes at least, a Money class represents "an amount of money", which can grow or shrink over time...
In this case, where you see this Money class as a container holding some amount of money, which can grow or shrink over time... Then of course, it has to be mutable!!! (as it holds an amount that can grow and shrink)
But, then I would argue that you probably could use a better name for your Money class... MoneyBag? Account?!?
Regards,
-a
|
Anonymous
Unregistered
|
|
One good reason for immutable objects is thread synchronization, it isn't necessary with immutable objects.
Not to say that this reason is sufficient enough!
|
Anonymous
Unregistered
|
|
I've would opt for immutable Money. This makes it consitent with other amount objects like Long, Integer, and Double. Making money immutable actually helps prevent obscure bugs and makes code more readable.
Code:
MyAccount account = .. getAccount
AccountView view =
new AccountView(account.getName(), account.getCredits().subtract(account.getDebits());
Do you see the bug?
This immutable code reads bettter and doesn't create a bug.
Code:
MyAccount account = .. getAccount
Money balance = account.getCredits().subtract(account.getDebits());
AccountView view =
new AccountView(account.getName(),balance);
|
Anonymous
Unregistered
|
|
You can translate the mutable/immutable into a real world example.
First, you can think 'immutable' money as a paper money - like Mr. Benjamine $20.
the'mutable' money is "gift certificate card", like Starbuck's card. You can put more money into the card.
The problem is when you are passing 'money' around.
For example, if I give you a green-paper mr. benjamin $20 to you. You can do whatever you want to do with it. I don't have to worry about it and you don't have to worry about it because it is yours.
But if I give you the gift card, I can increase your card amount by upgrading your gift card. Now, you have no clue how much money you have.
With immutable object, you don't have to worry about any other people changing the state.
That's why you have 'String' and 'StringBuffer'.
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
