Object-Oriented Clean Code

# CHAPTER 10

Object-Oriented Clean Code #

1. Introduction #

2. Learning Objectives #

• Distinguish between true Objects (Behavior) and Data Structures (State).

• Apply strict Encapsulation (hiding internals).

• Understand why deep Inheritance hierarchies are fragile and dangerous.

• Master the "Composition over Inheritance" design pattern.

• Design highly cohesive, loosely coupled classes.

3. Objects vs. Data Structures #

• Data Structures (DTOs): Expose their data (public variables) and have *no meaningful behavior* (no complex functions). They are just dumb containers for moving data around.

• Objects: Hide their data (private variables) and expose *behavior* (public functions). You do not ask an object for its data; you tell an object to do something.

• *The Rule:* Never create a hybrid. An entity should either be a pure Data Structure or a pure Object.

4. Encapsulation (Information Hiding) #

• The Problem: If you make an $accountBalance variable public, any random file in your application can do $user->accountBalance = 9000000;. Your system's data integrity is destroyed.

• The Solution: Make $accountBalance private. The only way to change it is by calling a public method: $user->deposit(100). Inside the deposit() method, the object enforces business rules (e.g., checking if the deposit is positive). The object acts as an impenetrable fortress protecting its data.

5. The Law of Demeter #

• The Train Wreck (Violation): $customer->getWallet()->getCreditCard()->charge(50);

• The Clean Way: $customer->charge(50);

6. Composition over Inheritance #

• The Problem (Fragile Base Class): You have a Vehicle class. Car and Boat inherit from it. You add a driveOnRoad() method to Vehicle. Suddenly, your Boat class breaks or inherits nonsensical methods. Deep inheritance trees are rigid and fragile.

• The Solution (Composition): Instead of *being* a Vehicle, a Car *has* an Engine, *has* Wheels, and *has* a Steering system. You build objects by composing smaller, single-responsibility objects together. This allows infinite flexibility without breaking inheritance trees.

7. Diagrams/Visual Suggestions #

[ BAD: Deep Inheritance ]
Animal
  |-- Mammal
       |-- Dog
       |-- Bat (Wait, Bats fly, but dogs don't. Where do we put fly()?)

[ CLEAN: Composition (Capabilities) ]
Dog: [ Has Fur ], [ Can Walk ], [ Can Bark ]
Bat: [ Has Fur ], [ Can Fly ], [ Can Echoloate ]
(We assemble objects from interfaces/traits rather than forcing a rigid family tree).

8. Best Practices #

• Small Classes: Just like functions, classes should be small. A class with 2,000 lines is a "God Class" that knows too much and does too much. It violates the Single Responsibility Principle. A class should be easily understandable in a few minutes.

9. Common Mistakes #

• Getters and Setters Everywhere: A developer makes all variables private, but then immediately generates a get() and set() method for every single variable. This is not Encapsulation! If you have a public setter for every variable, the data is essentially public. Only expose methods that represent valid business behaviors.

10. Mini Project: Refactor to Composition #

*After (Composition):*

class Character {
    private $movementType;
    private $combatType;

    public function __construct(IMovement $move, ICombat $combat) {
        $this->movementType = $move;
        $this->combatType = $combat;
    }
}
// Now we can inject a "FlyMovement" and "MagicCombat" into the same character easily!

11. Practice Exercises #

1. 1. Explain the "Law of Demeter" (The Principle of Least Knowledge). Why are "Train Wreck" method chains dangerous for code maintainability?

1. 2. Differentiate between a pure Object and a pure Data Structure.

12. MCQs with Answers #

13. Interview Questions #

• Q: A junior developer makes all class properties private, but generates a public Getter and Setter for every single property, claiming they have achieved "Encapsulation." Do you agree or disagree? Explain your reasoning.

• Q: Explain the "Fragile Base Class" problem. Give a real-world example of how a change to a parent class can unintentionally destroy a child class.

• Q: How does Dependency Injection rely heavily on the concept of Composition?

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #