Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a class which represents an entity object in our system (for sake of argument, a Customer object)

public class Customer()
{
  private int id;
  private String name;
  ... // 30+ fields

  public Customer()
  {
    // empty constructor!
  }

  // getters and setters
}

I'm trying to refactor this so that the fields are extracted into their own objects where they are more sensibly grouped, and at the same time creating parameterised constructors - with the intent I could then lose the setter methods and make my objects immutable (since this is apparently a Good Thing(TM)).

However, this doesn't make any sense - sometimes I need to update a customer's information! It's clearly not immutable. Should I just not make this class immutable - and can I apply the same argument to all my entity classes?

share|improve this question
7  
Why do you think it would be a good thing for your objects to be immutable? –  user16764 Mar 28 '13 at 17:06
    
@QmunkE when you say 'it does not make any sense', consider strings. They're immutable, yet you regularily update string variables. Also consider if strings were mutable, and how would you need to change your existing code to make it safe after that... Then consider, is it relevant for the way you use your own class. –  hyde Mar 29 '13 at 8:05

2 Answers 2

up vote 11 down vote accepted

What are the benefits of immutability? Do those benefits apply to a Customer object?

Generally, one uses immutability to provide determinism. Can you access an immutable object safely across multiple threads? Yes, because there's no danger of one thread mutating the object while another thread is processing it.

However, in the case of Line of Business applications, a database typically takes care of any concurrency problems by issuing locks on records when people edit them, or letting the last save win. Consequently, domain classes typically aren't designed in an immutable way, since doing so attempts to solve a problem that is already solved.

share|improve this answer

There is much field to cover between immutable types and exposing all the internals of your class through public setters.

A typical construct used for mutating immutable types is having methods akin to setters that return a copy of the object with updated values of certain fields - that is instead of having this:

public void setName (string value) {
   this.name = value;
}

you have something like this:

public Customer withName (string value) {
   Customer cust = this.Clone();
   cust.name = value;
   return cust;
}

That way you can have an immutable object that you can essentially update. Languages like F# have syntax sugar for similar operations on records, but in less functional OOP languages this seems unnatural. But anyway, this is probably not what you want to do.

What makes immutable state appealing is the fact that it makes lot of things easier to reason about, since the state won't change through a side effect in a piece of unrelated code - less places for things to go wrong. But it's just a means to the same end OOP languages encourage encapsulation for.

Instead of relying on setters, keep the updating logic inside the class. Same effect - less buttons to push and levers to pull to put your object in some unexpected and undesired state. Keep a well-defined interface for the consumers of your object to use and there will be no need for generic getters and setters.

It's more work than having your domain objects as simple Data Transfer Objects and it may sometimes be not worth it, so it's a judgement call. But if you're doing anything remotely complex with your object (and seeing you're looking at 30+ fields, you likely are), it might be well worth the effort.

share|improve this answer
    
It is pretty handy for Web applications where objects only live per request and are then disposed after the request is complete. At least for me it doesn't make sense to keep an elaborate long living object graph alive and updating it with each request. I prefer shared nothing and immutability is then more natural. –  Esailija Mar 29 '13 at 16:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.