Is it bad practice to use recursion in a constructor?

Question

I use Van Emde Boas trees, and I came across a situation where using recursion in a constructor is incredibly useful.

When I create the root of the node in the tree, the node will have pointers to many other nodes, and these nodes will point to many other nodes, etc. Even if they are initialized with null data, I still want them all there.

EDIT: In response to the comment, I thought this might be bad practice, because we should always be careful when allocating memory. In this case, the user may not be aware of the effects that allocate the new one, such a node may have, and therefore they can allocate more memory than they expected? In addition, it seems to me that just allocating / dangerous allocating memory in the constructor.

The code recursively creates new nodes until a complete tree is created. Is this a bad practice? If this is the best way to do this in Java?

//Constructor public VEBNode(int universeSize) { this.universeSize = universeSize; min = vEBTree.NULL; max = vEBTree.NULL; if(universeSize <= 2) { summary = null; cluster = null; } else { int childUnivereSize = (int)Math.sqrt(universeSize); summary = new VEBNode(childUnivereSize); cluster = new VEBNode[childUnivereSize]; for(int i = 0; i < childUnivereSize; i++) { cluster[i] = new VEBNode(childUnivereSize); } } } 

Answer 1

Usually you violate the "D" SOLID principles:

Dependency Inversion Principle

The principle reads:

a. High-level modules should not be dependent on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on the details. Details should depend on abstraction.

In fact, your constructor creates a specific class: self => not flexible enough and hard to test. (recursion mocks? :))

Answer 2

I can’t think of a case for which this can be considered bad practice.

Constructors are designed to fully assemble an instance of a class, so if recursion is required, it is not recommended to use it.

However, just for the sake of clarity, you might want to keep a simple constructor and implement recursion in another (private) method ... but that is up to you. Of course, if you put recursion in another method, you can call it from your constructor. The result is the same, but the code may look cleaner and more understandable.

Answer 3

In general, you can recommend making resource-intensive materials in the designer.

How about separating the "constructor" from the "building the whole tree"?

Also, are you planning on having subclasses?

Answer 4

The constructor is the place where you give birth to your object. It should be simple and straightforward.

If you need to initialize your object using some values, externalize the calculation of these values.

As I understand it, calling methods from the constructor is bad practice. I would use a delegate class that encapsulates all the logic.

Put all the complex logic in a separate service class (but again, not in the constructor) and use - delegate all the calculations to this service class.

The constructor is too sensitive a place to store complex (including recursive) logic.

Answer 5

If you intend to subclass this class, then recursion will bring you great pain, because you cannot override this constructor to create instances of the subclass.