Code Refactoring Changes

[AdilOtha]

trafficstars

Brief

I have refactored the code for selected Algorithms and Data Structures to improve structure, readability, reusability and remove duplicate code from some classes while preserving their behaviour.

Changes

• src/main/java/com/williamfiset/algorithms/datastructures/binarysearchtree/SplayTree.java:
  • split method:
    • I have refactored the code using the "Move Method" approach. The "split" method of SplayTree relied more on the methods of BinaryTree class. Hence, I have created a new method "split" in BinaryTree to get the left and right subtrees from the root node. This "split" method is called by SplayTree to retrieve the necessary left and right subtrees for inserting a new node and splaying it to the top.
    • I have renamed the variable "l_r" to "leftAndRightSubTrees" to conform to the Google Java Style Guide.
  • delete method:
    • There was a possibility of a NullPointerException while calling searchResult.getData(). I have added an extra condition to check if the searchresult variable is null to avoid this.
• src/main/java/com/williamfiset/algorithms/datastructures/hashtable
  • The "setupProbe" method of super-class HashTableOpenAddressingBase is only implemented by sub-class HashTableDoubleHashing. Other sub-classes HashTableLinearProbing and HashTableQuadraticProbing have empty implementations as they do not require probe setup. I have removed those empty implementations and removed "abstract" type in "setupProbing" method of super-class HashTableOpenAddressingBase and made it a normal method to be inherited or overridden by its sub-classes. This could be considered as a variation of the "Pull-Up Method" refactoring process.
• src/main/java/com/williamfiset/algorithms/datastructures/quadtree/QuadTree.java
  • The "knn" method shows signs of the "Long Method" implementation smell. I have extracted duplicate code sections and converted them into separate methods "findKnnRecursively" and "reprocessKnn". This could be considered refactoring using the "Extract Method" process.
  • I have also extracted the parameters "checkHorizontal", "checkVertical" and "checkDiagonal" into a separate class "CellType" for better cohesion and to avoid "Long Parameter List" implementation smell while extracting duplicate code sections. This could be considered refactoring using the "Extract Class" process.
• src/main/java/com/williamfiset/algorithms/strings/BoothsAlgorithm.java
  • Renamed variable "s" to "inputString" for better readability.
• src/main/java/com/williamfiset/algorithms/strings/BoyerMooreStringSearch.java
  • Renamed variables "t" and "p" to "inputText" and "pattern" for better readability.
• src/main/java/com/williamfiset/algorithms/dp/examples/domino-and-tromino-tiling/Solution.java
  • Renamed method "f" to "findCount"

Notes

• All test cases were successful after the code refactoring process. Hence, the behaviour of the code is preserved.
• The following is the list of refactoring methods applied and their references:
  • Move Method: https://refactoring.guru/move-method
  • Pull-up Method: https://refactoring.guru/pull-up-method
  • Extract Method: https://refactoring.guru/extract-method
  • Extract Class: https://refactoring.guru/extract-class
  • Rename Variable/Method: https://refactoring.guru/rename-method