Implement SplayTree

[sozelfist]

• 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 98.88889% with 1 line in your changes missing coverage. Please review.

Project coverage is 51.25%. Comparing base (b396a97) to head (155e54b).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
.../thealgorithms/datastructures/trees/SplayTree.java	98.88%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #5142      +/-   ##
============================================
+ Coverage     50.97%   51.25%   +0.28%     
- Complexity     3159     3193      +34     
============================================
  Files           523      524       +1     
  Lines         15104    15194      +90     
  Branches       2874     2893      +19     
============================================
+ Hits           7699     7788      +89     
  Misses         7084     7084              
- Partials        321      322       +1     

☔ 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).

[sozelfist]

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.

[sozelfist]

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.

[sozelfist]

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.

[sozelfist]

Can you have a look at the PR @vil02.

[sozelfist]

I have added a separate test for the uncovered line, I hope it covers that line.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution!

[siriak]

@alxkm @vil02 please take a look

[sozelfist]

Can you have a look, @alxkm?

[alxkm]

@TruongNhanNguyen, everything looks good. However, the build is currently failing. You need to add a serialVersionUID field to the exception classes, similar to this:

private static final long serialVersionUID = 1L;

Additionally, you haven't marked the key field as final in a few places. While it's optional, declaring it as final would indicate that the parameter is immutable and establish a constraint that can help prevent future modifications.

[sozelfist]

Let's have a look, @alxkm. I have updated the code based on the proposals and removed the redundant tests that are not necessary anymore (parametrized tests covered the lines that are covered by manual tests). Note that, the current tests do not fully cover the code, there is still 1 line partially covered.

Coverage is quite good