Implement SplayTree

[TruongNhanNguyen]

• I have read CONTRIBUTING.md.
• This pull request is all my own work -- I have not plagiarized it.
• All filenames are in PascalCase.
• All functions and variable names follow Java naming conventions.
• All new algorithms have a URL in their comments that points to Wikipedia or other similar explanations.
• All new code is formatted with clang-format -i --style=file path/to/your/file.java

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 95.06173% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 38.88%. Comparing base (8be8b95) to head (92a4b73).

Files	Patch %	Lines
.../thealgorithms/datastructures/trees/SplayTree.java	95.06%	0 Missing and 4 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #5142      +/-   ##
============================================
+ Coverage     38.58%   38.88%   +0.30%     
- Complexity     2378     2414      +36     
============================================
  Files           516      517       +1     
  Lines         15313    15394      +81     
  Branches       2957     2974      +17     
============================================
+ Hits           5908     5986      +78     
  Misses         9120     9120              
- Partials        285      288       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vil02]

What do you think about introducing a method: List<Integer> traverse(TraverseOrder traverseOrder), where TraverseOrder is an enum? This will allow to make the other methods private.

Does your implementation work for duplicated keys?

Please add the missing tests and please update your branch (there were some changes regarding the static analysis).

[TruongNhanNguyen]

Does your implementation work for duplicated keys?

The current implementation of the Splay Tree does not handle duplicate keys explicitly. Here are a few possible approaches:

1. Allow Duplicates: We can modify the implementation to allow duplicate keys. When inserting a node with a duplicate key, we can insert it as a new node in the tree or update an existing node with the same key.
2. Reject Duplicates: Alternatively, we can reject duplicate keys altogether. In this case, when inserting a node with a key already in the tree, we can either ignore the insertion or throw an exception to indicate that duplicates are not allowed.
3. Especially handle Duplicates: We can define a specific behavior for handling duplicate keys, such as keeping track of the number of occurrences of each key or maintaining a list of values associated with each key.

I think the simplest and most used approach is that when inserting a node with a duplicated key, we should update the existing node with the same key.

What do you think about these approaches, we will choose the one to implement.

[vil02]

I think we should not allow duplicate keys and explicitly throw an exception if one is trying to include already existing key. I looked at the existing implementations of BST in this repository and it is a total mess - each implementation reacts differently.

[TruongNhanNguyen]

I have updated the test cases, but there are a few partially covered lines. If you have any suggestion that make the code to be 100% covered, feel free to propose.

[TruongNhanNguyen]

I think we should not allow duplicate keys and explicitly throw an exception if one is trying to include an already existing key. I looked at the existing implementations of BST in this repository and it is a total mess - each implementation reacts differently.

I have refactored the implementation to disallow inserting duplicated keys and to throw an error if this occurs. I also handle deletion on an empty tree and simplify the deletion process.