Class structure: How should a binary tree and it's node class be implemented in Java in terms of class files?

Question

In implementing a binary tree in Java, should the node class be a separate class file independent of the BinaryTreeclass, or should it be a default class in the same class file as the BinaryTree class?

---

First Example: Node is in separate class file

BinaryTree.java

public class BinaryTree {
 ...
}

BinaryTreeNode.java

public class BinaryTreeNode {
 ...
}

---

Second Example: Node class is default class in same class file

BinaryTree.java

public class BinaryTree {
 ....
}
class BinaryTreeNode {
 ...
}

I almost never see the use case for putting more than one class inside of the same class file, but this might be the first time I see it being useful. Does this make sense, or would this be considered sloppy code?

• NoChance: Many examples are out there...take a look at: baeldung.com/java-binary-tree
• aCarella: @NoChance I don't think you read my question. I know there are a lot of example on how to implement a binary tree in general. I am specifically asking where my classes should go and if I should place two classes in the same file or not.
• NoChance: OK, I guess that implementing multiple classes in the same file is not a good practice. I think you should use single file-single class. I am not a java developer but in .NET this is the best approach. It allows you not only to quickly find classes easily, but also generate separate DLLs with ease. A discussion about it is here: quora.com/Can-we-keep-more-than-one-class-in-a-single-java-file

Answer 1

The problem with using default (package-protected) classes is that you won't be able to use that class outside of the package. For something like this, you typically want to.

There's a third option that I think is preferable. Use a nested class:

public class BinaryTree {
 // ...
 public static class Node {
 // ...
 }
}

Whether you make this a 'static' nested class or not depends on whether you want to implicitly associate each instance with a single parent BinaryTree or want to be able to create Nodes that can exist in 0-to-many trees.

In terms of compilation and usage, the static nested class is just like having a public class called BinaryTreeNode but with the name BinaryTree.Node.

There are a few advantages to this. One is that you keep the highly coupled code together in a single file. One really nice thing is that The BinaryTree can use private methods and values of the Node and vice-versa So you can keep things really well-encapsulated.

• Sebastian Redl: I think that in most cases, you don't want your binary tree to expose its node class without some abstraction around it.
• JimmyJames: @SebastianRedl I presume you mean an interface here. You can always define one and implement it with your inner class. You wouldn't need to make it public. You can even define BinaryTree.Node as an interface, if you like. It's not clear what advantage an interface provides here, we'd need more detail on the larger design.
• Sebastian Redl: Actually, the question is whether you even want to ever hand out a node. Maybe a Cursor (with different traversal orders) is a better abstraction. It depends on what the tree is for, of course.
• JimmyJames: @SebastianRedl Yeah, I had the same thought later. I still think nested/inner classes are nice for this. In the case you don't want to expose the nodes, you can make them strictly private. This isn't the case with a default class or separate public class.
• Sebastian Redl: "I still think nested/inner classes are nice for this." - I think they are perfect, because they can be made private.