Object-Oriented Programming: Java.Polynomial -- should methods be 'destructive'?

Question

I have to implement Java.Polynomial as a school assignment. Part of the methods are add(polynomial), multiply(polynomial) etc.

In the case of something like

p.add(q); // computes p + q

is it better to return void and keep the sum of the polynomials in p? or is it better to return a polynomial and keep the former value of p intact?

My instinct tells me that i should do the following

• implement p.add(q) as a 'destructive' method... it adds q to the value of p and stores the sum in p
• also implement a static method Polynomial.add(p,q) which returns the sum of the polynomials.

What do you think?

Answer 1

"It is better to return a polynomial and keep the former value of p intact"

Life is better if you make your numeric types behave like other numbers.

The "destructive" operations are a necessary evil when you have to optimize performance by reducing memory allocations.

The tradeoff is that your processing becomes opaque because of the more complex-looking state changes in the variables. You don't want hidden state change; you want your assignments of values to variables to be a big, obvious first-class, with-an-= kind of thing.

Answer 2

It's a matter of style. It's usually better (and "neater") when objects are immutable so methods are not "destructive" (they aren't mutators, they have no side effects) but return a new instance with the new value.

The most well known immutable class is String.

Answer 3

Personally I really like immutable types. I would write p.plus(q) instead of p.add(q) and make it return a new polynomial. Immutability has a lot going for it, not just in terms of thread-safety (which sounds like it won't be an issue in this case) but also in terms of reasoning about your code. It's a lot easier to predict what's going to happen if you know that nothing can change the contents of an object under your feet once you've stashed a reference to it.

Answer 4

Even if you do the "destructive" method, you're going to want to return the new value anyway to allow for function chaining. And, for what it's worth, when faced with the same problem for BigInteger and BigDecimal, Sun decided to go non-destructive.

Answer 5

So everyone is saying that you should make it immutable, and unless there are very specific performance reasons to make it mutable (you'll be adding a billion polynomials to a single magic one and don't want memory allocation), immutability is the way to go.

If you have genuine performance reasons, you may want to have a destructive and a non-destructive version, but remember -- this leads to confusion. I think your idea of overloading add to be destructive or not based on the arity will make things very, very confusing. Better make everything non-destructive and make a addDestructive(poly p) method if you choose.

Answer 6

Make it immutable, and make the interface the same as for BigInteger (as far as applicable).

Answer 7

is it better to return void and keep the sum of the polynomials in p?

Not bad, not necessarily better either.

or is it better to return a polynomial and keep the former value of p intact?

It is better, less surprises and code easier to understand and maintain. ( although you will have to create more variables )

Answer 8

A polynomial has a fixed value in terms of its variables, and thus it only really makes sense for it to be immutable. Return a new Polynomial for your operations.