Java Private Constructor Cleverness?

Hello there.

Uh... hi.

Are you ready to talk about Java?

For a little while at least.

I'll try not to bore you then. Let's get right to it... Does your project have a StringUtils class?

Of course. Everyone has a StringUtils. Ours is just a bunch of methods that operate on Strings.

I thought so, it's pretty common. Does its lack of OO purity bother you?

Oh geez. Go preach to someone else.

But doesn't it make extending the system harder? Doesn't it make unit testing hard?

My StringUtils has never been an issue.

Maybe StringUtils isn't the best example. Does your project have a StateMachineUtils?

That class sounds a little suspect.

Indeed it does. Can you imagine why it might be a poor idea?

Hmm. Tight coupling? Static dependencies?

Sure. Static methods in Java create a compile-time dependency on that specific method and class. As your system grows, you can't swap out the utility class with a different one in order to change the behavior of an object. A more immediate concern is that you can't swap out the utility class during testing in order to isolate your class under test. Every test becomes an integration test, retesting all the dependencies.

Still, my StringUtils has never been an issue. Sure it's procedural, statically bound code, but as long as you don't abuse it things should be alright.

Exactly. If your import statements are filled with java.lang references, then don't worry. If they are filled with java.sql or java.awt then think twice.

The Law of Utility Classes

Be wary of the dependencies in utility classes to avoid abusing them.

Is that all?

No. What I really wanted to talk about was private constructors.   class StringUtils {     //never instantiate a utility class     private StringUtils() {}   }

Ah yes, I've seen this before. It makes it impossible to instantiate an object of type StringUtils. Seems prudent.

Yup. It's been a Java best practice since the days of Effective Java 1st Edition*. If your class is not meant to be instantiated then don't allow people to do it. Without the private constructor, Java will create a default one for you that is public. The private constructor will make it impossible subclass or instantiate the utility class. The item is called "Enforce noninstantiability with private constructor". * Thank you J. Bloch (1967 - )

The Second Law of Utility Classes

Provide a private constructor to enforce noninstantiability.

Sure. No arguments here.

But you can still instantiate the object, can't you?

You can do anything with reflection, right?

Sure, but there is a simpler way. How about creating an instance from within StringUtils itself. Any method within StringUtils is still free to reference the private constructor. Do you know how to prevent this?

I suppose you could make the private constructor throw an exception.

Right.   class StringUtils {     //never instantiate a utility class     private StringUtils() {         throw new AssertionError();     }   }

What good is this?

Now there is no way to create an instance, even if a programmer inside your class decides that it should be done. If there is no sense in having instances then make it impossible to do so. It is the ultimate safety. If something should not be done, then prohibit it.

Can't I still create an instance with cglib, using libraries like EasyMock?

Yes. This isn't perfect, but it is safer.

The Third Law of Utility Classes?

Enforce noninstantiability with private constructor that throw exceptions.

Is this really a solution to a problem? Is your problem really maintenance programmers modifying classes when they don't have enough understanding to know when it isn't appropriate to instantiate a class?

Well, no. I don't have that problem. We've had our share of poor developers come through our doors over the years, but this particular issue never arose.

What's the impact if someone did instantiate millions of these objects? Is it any different than if a naive programmer constructed millions of any non-utility objects.

I guess not. Nothing that a profiling session wouldn't reveal, at any rate.

It sounds like this third law is optional. There's not a large benefit to following it. Is this why the law contains a question mark?

I suppose it is. The question mark was my way of saying, "Maybe this law isn't always a maxim." So the third law is optional, but the first two are certainly worth adhering too.

I'm not sure the second law is all that different from the third. Both guard against a programmer doing something nonsensical but harmless.

Are you saying it is alright to leave out the private constructor on a utility class? That the second law should contain a question mark also?

It does seem like extra work to prevent the possibility of a harmless and naive mistake on someone else's part. I'd say it comes down to a style and cultural issue.

Cultural issue? How is safety a cultural issue?

Do you know the difference between a Directing Attitude and an Enabling Attitude?

I think I've heard the terms before.

A directing attitude attempts to prevent programmers from doing the wrong thing, limiting what they can do in order to limit their mistakes. An enabling attitude attempts to give programmers the freedom to do whatever they need to do. Designs should make things easy to use well but not prevent mistakes.* Thank you M. Fowler (1962 - )

I would say mainstream Java favors the directing attitude.

Perhaps. But it would be OK for an enabling attitude to be taken, and to stop writing private constructors just to prevent mistakes.

I see how this would be acceptable in some workplaces. It's not the typical Java way, but could be done. So neither the Second Law nor the Third Law are laws at all, but simply preferences. At least we have created one Law out of all this, the First Law.

Are you sure?

Quite. Utility classes have their place, but overuse makes the system difficult to extend. Composition, small classes, and OO make software more malleable, and utility classes typically subvert this.

A lot of languages don't have objects. How do they get by?

We're talking about Java here, so there's no point in asking that question. The First Law should stand as a law.

OK. But don't forget, there are a lot of other languages out there too, even some that run on the JVM.

Yeah, yeah. Polyglot whatever.

I think we're both tired. Are we done here?

Yeah, we're done. Now go make yourself some cookies, you deserve it.