For example, we could use longer generic param names, like:
//instead of this
public class BST<E, K> implements BstADT<E, K>
//we could do something like
public class BST<ElementType, KeyType> implements BstADT<ElementType, KeyType>
//or as we wish -- we would just want to put short "legend" in class header of what
//each generic param used on class means (especially if using one letter)
For example-sake, let us assume we have a project root directory
"c:\work\projects\bst-project\".
IDE's will often add a sub-directory "src" that is on the classpath (i.e. Java will search in "src"). In this case we would end up with our two sub-directories like this:
c:\work\projects\bst-project\src\bst
c:\work\projects\bst-project\src\treepub
We could also put sub-diretories directly below the project directory "bst-project" (as long as it is on the classpath). We would then have:
c:\work\projects\bst-project\bst
c:\work\projects\bst-project\treepub
The key thing is that the parent directory (that holds our "bst" and "treepub" sub-directories) is on the classpath.
Note that the IDE often does not require us to think about "classpath" -- it takes care of it for us -- this is great but we still want to understand classpath.
Side note: In either case, for this example, we would simply submit the entire project directory, e.g., "bst-project"
I like to put the core logic (navigation for inserting and searching) into the node and keep the tree lightweight. It just seems to me that the node is the expert on navigating left/right etc.
Note, if you do put the core logic in the node, you'll likely have to pass the sortFct or the searchFct, as appropriate, from the tree to the node, when the tree is calling node methods that need it.
Data Structures And Algorithms (DSA)
(Chapter 704 - BST Coding Challenge)