Refactoring practice

1. CLEANER CODE
REFACTORING PRACTICE

2. REFACTORING PRACTICES: CLEANER CODE
TABLE OF CONTENTS
▸ Motivation
▸ What is CLEAN CODE?
▸ Refactoring Practices
▸ Practice Scope
▸ Practice1: NumberAnalysis.java
▸ Practice2: TicTacToe.java
▸ Lessons Learned
2

3. MOTIVATION
▸ For deeper understanding of OOP and java
▸ Curious about more advanced coding styles
I searched proper references and chose the book!
Clean Code
A Handbook of Agile Software Craftsmanship
by Robert Cecil Martin
3REFACTORING PRACTICES: CLEANER CODE

4. WHAT IS CLEAN CODE? (1/2)
▸ What is defined as clean code differs from each individual
but the base is shown below:
CLEAN CODE
straightforward
easy to read
easy to understand
easy to maintain
good performance
lower dependency
higher cohesiveness
meaningful name
…
easy to enhance
…
4REFACTORING PRACTICES: CLEANER CODE

5. WHAT IS CLEAN CODE? (2/2)
▸ Martin explains the concept of clean code in a simple
manner, just like how the code should be.
▸ Clean code starts from variable and method names that
describes its function, each method having only one
function. This way, even the most complex class can be
easily read when put all together.
▸ Any code can be converted into clean code with a little bit
of refactoring.
5REFACTORING PRACTICES: CLEANER CODE

6. REFACTORING
PRACTICES

7. PRACTICE SCOPE
▸ Easily-read statements
▸ Intention-revealing naming that follows Java’s naming
conventions
▸ Simple methods
▸ Single responsibility for each Class
▸ Revealing OO-concepts in codes
7REFACTORING PRACTICES: CLEANER CODE

8. PRACTICE 1
ANALYSING NUMBERS

9. PRACTICE 1
ANALYSING NUMBERS
▸ Program Purpose: AP Computer Science homework
intended to practice a wide array of Java concepts
▸ Requirements:
1. It should be written in the form of a console program.
2. Various kinds of operations should be provided.
3. Operation selection should be repetitive.
9

10. PRACTICE 1
ANALYSING NUMBERS
▸ Example of Program Execution
10
Input from keyboard
Operation choice
Operation choice

11. PRACTICE 1
CLASS DIAGRAM OF INITIAL CODE
11
A list of numbers to be calculated
An array for making histogram
An array for obtaining modulus
Displaying repetitive prompts

12. PRACTICE 1
MAIN() METHOD
Keep storing numbers
from keyboard
until the value is zero
Make a choice and
display the result

13. PRACTICE 1
PROBLEMS (1/2)
13
Vague Naming
Method names
not following Java naming convention
Wrong visibility

14. PRACTICE 1
PROBLEMS (2/2)
14
Hard to understand
Hard to read
Indistinct identifier

15. PRACTICE 1
REFACTORED
▸ Class Diagram
15
Class name, variables and methods
renamed
Methods extracted
Visibility corrected
Constant added

16. PRACTICE 1
REFACTORED
▸ main() and public method run()
16
Test code with high readability
by extracting a method
and correcting visibility.
Now,
fillNumberArray() and run() are visible
in main() method and
run() uses the private methods inside.

17. PRACTICE 2
TIC-TAC-TOE

18. PRACTICE 2
TIC-TAC-TOE
▸ Requirements
1. Display the game board and the respected crosses
and noughts with symbols.
2. Game continues until a player wins or ties.
18

19. PRACTICE 2
TIC-TAC-TOE
▸ Example of Program Execution
19
Initial game board
Pick a row
and column
in turn
Game End
and
display a board

20. PRACTICE 2
CLASS DIAGRAM OF INITIAL IMPLEMENTATION
20
A constructor initialising and print
the game board
A method that checks to see if a player has won or tied
An array that contains the game board

21. PRACTICE 2
PROBLEMS (1/2)
21
Unclear variable name
Different functions contained
in one method
Method name
breaking naming convention

22. PRACTICE 2
PROBLEMS (2/2)
22
Bug latent
I found the bug that already-chosen cell can be replaced
in the refactoring process.

23. PRACTICE 2
CLASS DIAGRAM OF CODE REFACTORED
23
Constant variables created
The board and the parameters renamed Methods split so each has one function
Class dissection

24. PRACTICE 2
HOWEVER, I THOUGHT..
24
TicTacToe.java still seems heavy.
Local variables might not be necessary.
Ways to eliminate error-prone code?
Is the class dissection right?
…

25. PRACTICE 2
REFACTORING ONCE AGAIN
25
+ Three valid states
+ Clearer relations among classes
+ More understandable classes
and its role
Now,
ü it became more
understandable and
maintainable structure.
ü I made reusable classes.
ü Unintentionally I fixed a bug.

26. LESSONS LEARNED (1/2)
▸ I had a chance to review bad code smells in my code.
▸ In the refactored code,
▸ methods and classes are much easier to read.
▸ the sub methods are easier to maintain.
▸ code becomes easier to read and understand without
the need of comments.
▸ code becomes maintainable for future bugs and/or
tweaks.
26REFACTORING PRACTICES: CLEANER CODE

27. LESSONS LEARNED (2/2)
▸ To keep coming back to the code and revise it makes
better code.
▸ Refactoring can be those important and meaningful
practice.
▸ Keep in mind “The Boy Scout Rule”
27REFACTORING PRACTICES: CLEANER CODE