CS3003 - Lecture 3 - Software Structure, Refactoring and Code Smells

What are the important laws in software engineering?

- Law of Demeter (LoD) or Principle of Least Knowledge

- Single Responsibility Principle (SRP)

What is Law of Demeter?

The design guideline that a class should have limited knowledge of other classes, interacting only with its "closely related" or "immediate friends". Discourages direct communication with "strangers" to minimise coupling.

According to the Law of Demeter, how should messages be sent?

- To the object itself

- The objects passed as parameters to the method

- Objects created within the method

- Direct component objects

What is the SRP?

Single Responsibility Principle. A class should only have one reason to change, meaning it should only have one responsibility. A class adhering to SRP will have high cohesion and low coupling.

Why does software degrade?

- Bugs lead to rushed maintenance and improper fixes

- As code ages, coupling rises, more complexity

- Technical debt accumulates when work is postponed

- Violations of LoD and SRP

How is the degradation of software visualised on the bathtub curve?

Failure rate increases in the "Wearout failures" phase

What is Refactoring?

The process of changing a software system in such a way that it does not alter the external behaviour of the code, yet it improves the internal structure.

What are the purposes of Refactoring? (4)

- Reduce duplicate and inefficient code

- Improve cohesion and reduce unnecessary coupling

- Improve understandability and maintainability

- Reduce technical debt

When is it important to Refactor?

- Consistently and mercilessly

- When a "bad smell" is recognised

- When fixing a bug, or after fixing a bug to improve the surrounding code

- During code reviews as a part of mob programming

What types of maintenance is Refactoring?

Preventative and Perfective

What are the 10 forms of classic refactoring

- Extract method

- Extract class

- Extract subclass

- Move method

- Move field

- Encapsulate field

- Replace magic numbers

- Removing dead code

- Consolidate conditional duplicate fragments

- Substitute algorithm

Refactoring - What is Extract Method?

Turning a code fragment within a longer method into a new method whose name explains its purpose.

Refactoring - Extract Class?

If one class is doing work that should be done by two, create a new class and move relevant fields and methods to it. (it may introduce coupling however)

Refactoring - Extract Subclass?

If a class has features only useful in specialised instances, create a subclass and move those features to it.

Refactoring - Move Method

If a method is used more by another class than its own or uses features of another class, move the method to the class that uses it most.

Refactoring - Move Field

If a field is used more by another class than its own, move it to the class that uses it most to improve cohesion or reduce coupling.

Refactoring - Encapsulate Field?

Changing a public field to private and providing public accessor methods (getter/setter) - improving encapsulation

Refactoring - Replacing Magic Numbers?

Replacing a literal number like 3.14 to a named constant like pi. This improves readability and maintainability as the value only needs to be changed in one place.

Refactoring - Removing Dead Code?

Deleting code that is never executed for tidiness.

Refactoring - Consolidate Conditional Duplicate Fragments

If identical code exists in all branches of a conditional, place it outside the conditional

Refactoring - Substitute Algorithm

Replacing an algorithm with one that is clearer or more efficient but achieves the same result.

What are the Advantages of Refactoring?

- Reduce duplicate or inefficient code

- Improves cohesion and reduces coupling

- Improves understandability and maintainability by reducing complexity

- Can reduce technical debt

- Can help reduce bugs as code is more maintainable

- Can be done at any stage of a system's life

Disadvantages of Refactoring?

- Opportunity cost - time spent can be spent on other tasks like new features

- Requires retesting

- Can introduce bugs

- Requires time and communication

- Lack of empirical evidence

- Rabbit Holes - may get sidetracked

What are Code Smells?

Rotten structures in code or coding horrors, that indicate potential problems that suggest the need for refactoring.

- stench is an unbearable smell

What are examples of code smells? (7)

- Large Class

- Long Parameter List

- Lazy Class

- Solution Sprawl

- Data Class

- Refused Bequest

- Comments

Code Smells - Large Class?

A class that tries to do too much, violating SRP, often having low cohesion. Refactor using Extract Class. Sometimes may be valid if all methods really do contribute to a single, complex responsibility

Code Smells - Long Parameter List?

A method with too many parameters is hard to understand and can be inconsistent. Resolve by removing or grouping parameters.

Code Smells - Lazy Class?

A class that is too small that does not do enough to justify its existence. May be a result of previous refactoring, consider merging or removing

Code Smells - Solution Sprawl

When making a change to a feature requires modifications in many different components across many different classes - this indicates poor modularity

Code Smells - Data Class

Classes with fields, getters, and setters, but nothing else. Objects should ideally combine data and behviour

Code Smells - Refused Bequest

A subclass ignores or doesn't use most of the functionality provided by its superclass. Indicates incorrect inheritance hierarchy.

Code Smells - Comments

Comments are good but excessive comments indicate bad code. Good code should speak for itself - self-evident through short methods and meaningful names. Comments should explain WHY not WHAT.

What is the Rule of Three

This rule states that you are allowed to copy and paste code once. When the same code appears a third time, it should be extracted into a new, unique method to avoid excessive duplication.

What is defensive programming?

A technique where you assume the worst for all inputs to make the code more robust and easier to maintain. Links to cybersecurity.

What are the rules of defensive programming?

- Never assume anything about the inputs

- Use and stick to proper coding standards

- Keep code as simple as possible (KISS)

- Reuse trusted and documented code e.g libraries