Java Mutable and Immutable objects

Mutable objects have fields that can be changed, immutable objects have no fields that can be changed after the object is created.

A very simple immutable object is a object without any field. (For example a simple Comparator Implementation).

class Mutable{
  private int value;

  public Mutable(int value) {
     this.value = value;
  }

  getter and setter for value
}

class Immutable {
  private final int value;

  public Immutable(int value) {
     this.value = value;
  }

  only getter
}

Example

Mutable objects can have their fields changed after construction. Immutable objects cannot.
public class MutableClass {

 private int value;

 public MutableClass(int aValue) {
  value = aValue;
 }

 public void setValue(int aValue) {
  value = aValue;
 }

 public getValue() {
  return value;
 }

}

public class ImmutableClass {

 private final int value;

 public MutableClass(final int aValue) {
  //The value is set. Now, and forever.
  value = aValue;
 }

 public final getValue() {
  return value;
 }

}

Agile Programmer Thinking

I’m Stuck

Recently I found myself in several situations where I just couldn’t write code. Or at least, “good code”

First, I had “writer’s block”. I just could not see what was going to be my next test to write.

I could not find the name for the class / interface I needed.

Second, I just couldn’t simplify my code. Each time I tried to change something (class / method) to a simpler construction, things got worse. Sometimes to break.

I was stuck.

The Tasks

Refactor to Patterns

One of the situations we had was to refactor a certain piece in the code.

This piece of code is the manual wiring part. We use DI pattern in ALL of our system, but due to some technical constraints, we must do the injection by hand. We can live with that.

So the refactor in the wiring part would have given us a nice option to change some of the implementation during boot.

Some of the concrete classes should be different than others based on some flags.

The design patterns we understood we would need were: Factory Method and Abstract Factory

The last remark is important to understand why I had those difficulties.

I will get to it later.

New Module

Another task was to create a new module that gets some input items, extract data from them, send it to a service, parse the response, modify the data accordingly and returns items with modified data.

While talking about it with a peer, we understood we needed several classes.

As always we wanted to have high quality code by using the known OOD principles wherever we could apply them.

So What Went Wrong?

In the case of refactoring the wiring part, I constantly tried to immediately create the end result of the abstract factory and the factory method that would call it.

There are a-lot of details in that wiring code. Some are common and some needed to be separated by the factory.

I just couldn’t find the correct places to extract to methods and then to other class.

Each time I had to move code from one location and dependency to another.

I couldn’t tell what exactly the factory’s signature and methods would be.

In the case of the new module, I knew that I want several classes. Each has one responsibility. I knew I want some level of abstraction and good encapsulation.

So I kept trying to create this great encapsulated abstract data structure. And the code kept being extremely complicated.

Important note: I always to test first approach.

Each time I tried to create a test for a certain behavior, it was really really complicated.

I stopped

Went to have a cup of coffee.

I went to read some unrelated stuff.

And I talked to one of my peers.

We both understood what we needed to do.

I went home…

And then it hit me

The problem I had was that I knew were I needed to go, but instead of taking small steps, I kept trying to take one big leap at once.

Which brings me to the analogy of Agile to good programming habits (and TDD would be one of them).

Agile and Programming Analogy

One of the advantages in Agile development that I really like is the small steps (iteration) we do in order to reach our goal.

Check the two pictures below.

One shows how we aim towards a far away goal and probably miss.

The other shows how we divide to iterations and aim incrementally.

Aiming From Far

Aiming Iterative and Incremental

Develop in Small Incremental Iterations

This is the moral of the story.

Even if you know exactly how the structure of the classes should look like.

Even if you know exactly which design pattern to use.

Even if you know what to do.

Even if you know exactly how the end result should look like.

Keep on using the methods and practices that brings you to the goal in the safest and fastest way.

Do small steps.

Test each step.

Increment the functionality of the code in small chucks.

TDD.

Pair.

Keep calm.

Refactor Big Leap

Refactor Small Steps