Comments on: Coding: Setters reduce trust

By: Good Lazy and Bad Lazy at Mark Needham

Good Lazy and Bad Lazy at Mark Needham — Tue, 21 Jul 2009 13:12:43 +0000

[...] Adding setters to a class when we have some extra data that we want to put inside that class instead of taking the time to either change the constructor to take in the new data or considering if we now need to create a new class to better represent the system. The problem here is that we end up with objects that may be half initialised which makes them really difficult to work with later on. [...]

By: Gil Zilberfeld

Gil Zilberfeld — Mon, 25 May 2009 05:36:10 +0000

It’s an interesting point of view. I can definitely see the why you would use immutable objects, when needed.
I do have an aversion for big constructors (with many params) as the code is less readable, and therefore lowering the maintainability of the code – the same thing we’re trying to avoid by making objects immutable.

I do agree with a better IDE suggestion. Get the best tool you can – they will make your life easier.

By: SCdF

SCdF — Mon, 25 May 2009 00:09:45 +0000

You’re right in theory.

However, I have come across situations where being able to ‘partially’ initilise objects comes in handy, mostly when it means you can create a reference to the object before all the data it requires is available.

I once had to deal with a data structure that someone had written that was similar to a graph. Defining a node that points to another node that points back to that node was impossible without modifying the code to provide setters.

Granted, this is due to the arguably bad design of the data structure, but I do think there are legitimate uses for this.

As an aside, wrt the “it turns refactoring from a single change to a constructor argument to a line-by-line search for property assignments” comment– get a better IDE .

By: Morten Lyhr

Morten Lyhr — Sun, 24 May 2009 19:23:46 +0000

Actually a setter on a real object, that pretty much always breaks encapsulation.

On the other hand if it is data object(some call it DTO), there is no reason not to have properties with setters.

I tend to have properties in pure data objects with no logic and no properties in my real objects. The real objects can depend on a data objects, just like it can depend on a simple type like strins, ints etc. Data objects can also be returned from real objects like the result of a calculation.

By: Ryan Riley

Ryan Riley — Sat, 23 May 2009 17:38:35 +0000

Well said. I’m very hesitant to just rely on setters. In general, I try not to use setters whatsoever. After learning a bit about the benefits of immutability, I really have a hard time allowing things to change after they are set. I find myself using the Builder pattern to store up what I want and then passing those parameters into a constructor or loading a DTO to load my domain models. No setters necessary.

@Tim, I don’t think you can just discount null reference checks as setter issues. I’ve seen numerous cases where nulls are passed into the constructors and caused the same issues.

By: Tim Robinson

Tim Robinson — Sat, 23 May 2009 08:47:06 +0000

You’re right that having extra initialization to do after constructing an object reduces trust in that class — I hate coming across code full of null reference checks (on properties that can never be null) because somebody got bitten by an exception once.

The other thing you lose with setter properties, compared to constructor arguments, is the ability to track where data comes from and when.

Because a property is writable, you can never be sure that some other piece of code overwrites your value later on: it turns refactoring from a single change to a constructor argument to a line-by-line search for property assignments.