Java Code Quality – Are init() Methods a Code Smell?

code smellcode-qualityjavaobject-orientedobject-oriented-design

Is there any purpose for declaring an init() method for a type?

I'm not asking whether we should prefer init() over a constructor or how to avoid declaring init().

I'm asking if there is any rationale behind declaring an init() method (seeing how common it is) or if it's a code smell and should be avoided.

The init() idiom is quite common, but I have yet to see any real benefit.

I'm talking about types that encourage initialization via a method:

class Demo {
    public void init() {
        //...
    }
}

When will this ever be of use in production code?

I feel it may be a code smell since it suggests the constructor does not fully initialize the object, resulting in a partially created object. The object should not exist if it's state isn't set.

This makes me believe it may be part of some kind of technique used to speed up production, in the sense of enterprise applications. It is the only logical reason I can think of having such an idiom, I'm just not sure how it would be beneficial if so.

Best Answer

Yes, it's a code smell. A code smell isn't something that necessarily always needs to get removed. It's something that makes you take a second look.

Here you have an object in two fundamentally different states: pre-init and post-init. Those states have different responsibilities, different methods that are allowed to be called, and different behavior. It's effectively two different classes.

If you physically make them two separate classes you will statically remove a whole class of potential bugs, at the cost of maybe making your model not match the "real world model" quite as closely. You usually name the first one Config or Setup or something like that.

So next time, try refactoring your construct-init idioms into two-class models and see how it turns out for you.

Related Solutions

Java – Why Multiple Calls to Same Class Constructor Fail

Constructors are not just "methods that are called when object is created", they are conceptually different.

Constructor's purpose is to constrain what states objects can be in initially. A freshly created object is zeroed on all fields (null/0/false) and that may be an invalid state in your program. For example, a Customer object in your application needs be constrained to always have a customerId > 0 — you then define a constructor that takes that id and checks it.

In this light there is no purpose in calling two constructors: after calling the first one the object is already in a consistent state. The second constructor will receive an initialized object which is a breach of its purpose (doing 0 => initialized).

What you want to do in this case is either introduce private methods that will do parts of that initialization and call them or make more specific constructors call the more general one (which is a very common pattern):

Foo (int d, String n) {
    digit = d;
    name = n;
}

Foo (int p) {
    this(p, null)
}

Foo (String q) {
    this(0, q)
}

Python Static Utility Class – Best Way to Create and Is Using Metaclasses a Code Smell?

I think it is a bad idea.

Its a very odd use of meta classes which will contribute to confusion of anyone trying to follow your code. In order to make it worth using this technique, you need the advantages to outweigh that confusion.

As for your reasons:

Creating an accesible Foo class that can be instantiated, but doesn't actually work like a typical object is much more prone to misuse than an internal class that you know you aren't supposed to call.
Don't name the base class with an underscore. If its intended to be inherited by other modules, it shouldn't be named that way.
There already is a method to implement static classes in python, staticmethod or classmethod. As noted, its not hard to implement a staticproperty

In general, there is a theme in your approach of trying to prevent client code from doing the wrong thing. That's not a pythonic attitude. The pythonic approach is to trust your client code. If they want to do something crazy, let them. Don't try to prevent client from instantiating your internal object, there may well be a good reason to do that.

I'm a bit of a purist and think that you shouldn't be storing state like this. So the very fact that you are asking the question means you're already doing it wrong. If you have state, I think it should be in an object. I think storing any sort of state at the module level should be avoided. I think its only a good idea to implement something like this if you have no changing state.

To close off, I'd like to plug the Code Review Stack Exchange, where I'm a moderator. If you post your code there you can get suggestions on how to make it better. I think you may get some helpful suggestions for how to restructure your code to avoid this question from even coming up.

Best Answer

Related Solutions

Java – Why Multiple Calls to Same Class Constructor Fail

Python Static Utility Class – Best Way to Create and Is Using Metaclasses a Code Smell?

Related Topic