Comments on: Primitive Obsession II: (Im)mutability and Redefining Primitive

By: Aviad Ben Dov

Aviad Ben Dov — Tue, 11 Dec 2007 12:09:16 +0000

It’s true unless your work is all around cycles, where they become precious, but you still want to work with Java and not C or some other low-level language.

Take a look at a project called Javoloution which does just that.

By: Daniel

Daniel — Mon, 10 Dec 2007 16:28:07 +0000

The JVM has become so good at managing memory, that its considered dangerous to use object pools, as it could actually disrupt the GC’s normal processing. However, they point is that unless a profiler tells you that object-creation of this particular type is what’s taking up all your time, don’t bother optimizing it. Cycles aren’t the precious commodity they used to be.

By: Aviad Ben Dov

Aviad Ben Dov — Mon, 10 Dec 2007 12:50:55 +0000

Also, to answer the question about overheads of objects, its true that there’s an overhead but there are two benefits for immutable objects: first, they can use the flyweight design pattern very easily (see Integer.valueOf and the likes, so that there would be an Angle.valueOf(double) that would return very common angles as flyweight instances). Second, they can use an object pool of internally mutable objects, so that “Angle.valueOf” would ask the pool for an Angle with a certain degree and would receive a previously allocated object, modified to the angle required. That would save quite a lot of time for the virtual memory manager, reducing the strain on the system.

By: Aviad Ben Dov

Aviad Ben Dov — Mon, 10 Dec 2007 12:44:45 +0000

I think that you brought a lot of good points. I think that in this case, another good point can be made for Boolean values: A lot of the times boolean values are used but without a lot of readable sense. For example, the following: “new DatabaseTable(”my_table”, true, false, true)” or: “new DatabaseTable(”my_table”, CACHED, NO_FAULTING, AUTOMATIC_TRANSACTIONS)”.

The idea is to use Enums where reasonable to depict true/false values, to make the application (a) more readable, and (b) more robust for future changes (if an intermediate value is suddenly required).

By: Daniel

Daniel — Tue, 06 Nov 2007 01:20:09 +0000

@Roedy
Thanks for the feedback. It was kind of meandering, and I should structure it a bit better. As for the overhead of using objects, my main goal is to describe good OO architecture/design. My personal preference is to use objects in all cases, unless you find, through proper profiling, that using the object version causes problems.

By: Roedy Green

Roedy Green — Mon, 05 Nov 2007 21:37:47 +0000

The essay needs to have the structure:
1. tell them what you are going to tell them.
2. tell them
3. tell them what you told them.

The way it is written, it is frustrating not knowing where it is headed or what the essential point is.
It feels very meandering.

You also ignore the key issue of overhead of using objects instead of primitives. How do you decide which to use in any given case?

By: Roedy Green

Roedy Green — Mon, 05 Nov 2007 21:33:20 +0000

“value in a specific set of real,”
should be
“value in a specific set of reals,”

By: Roedy Green

Roedy Green — Mon, 05 Nov 2007 21:32:42 +0000

“Just as Integer object”
should be
“Just as an Integer object”

By: Roedy Green

Roedy Green — Mon, 05 Nov 2007 21:31:48 +0000

“Lets say that I have a value that represents an angle.”
should be
“Let’s say that I have a value that represents an angle.”

By: Roedy Green

Roedy Green — Mon, 05 Nov 2007 21:31:13 +0000

“to represent you data”.
should be “to represent your data”