The Five Principles of Harmony: A Fantasy Journey Through the SOLID Principles

In the heart of the kingdom of Artefatos, where magic and artifact creation ruled the world, a perfect balance reigned. Each enchanted object had a specific purpose, and the kingdom thrived on order and structure.

But the shadow of chaos spread over Artefatos when the dark wizard Fastaroth introduced his ultimate artifact: the Unravelor. This object, designed to do everything, began to fail, resulting in malfunctions and destruction. Bridges collapsed, towers exploded and wizards could no longer control their spells.

The wise men of the kingdom consulted the ancient writings and found a prophecy: only those who understood the Five Principles of Harmony could restore order. The young magician Refactor, known for his dedication and desire to improve, set out to meet the five oracles and learn the fundamental principles.

First Test: The Principle of Single Responsibility

Through the ruins of an ancient temple, Refactor encountered the First Oracle, the Sage of Balance.

“I am the guardian of the Single Responsibility. Each artifact must have a single, well-defined purpose, otherwise confusion and chaos will prevail. Show me that you understand this principle!”

An ancient scroll appeared in front of Refactor, engraved with the enchanted code:

class Incantesimo {
    void accendereTorcia() {
        // Logica per accendere una torcia
    }
    void lanciareScudoMagico() {
        // Logica per creare uno scudo di protezione
    }
}

Refactor looked at the code and realized the problem. A class wasn’t supposed to have multiple responsibilities, and here the spell handled both light and defense. He took his wand and separated the functions:

class TorciaMagica {
    void accendereTorcia() {
        // Logica per accendere una torcia
    }
}

class ScudoMagico {
    void lanciareScudo() {
        // Logica per creare uno scudo di protezione
    }
}

The Sage of Balance nodded with satisfaction.

“You have learned your lesson. Each artifact must have only one purpose, so as to maintain clarity and simplicity.”

Second Test: The Open-Closed Principle

In the Palace of Knowledge, Refactor met the Second Oracle, the Queen of Wisdom.

“I uphold the Open-Closed principle. Code must be open to extension, but closed to modification. Now, prove to me that you can respect this rule.”

He was given a snippet of code:

class SpadaMagica {
    void attacca() {
        System.out.println("Colpo base");
    }
}

But Refactor knew that if someone wanted to add a buff to the sword, they would have to modify this class directly. He then thought of a more modular solution:

interface Attacco {
    void esegui();
}

class ColpoBase implements Attacco {
    public void esegui() {
        System.out.println("Colpo base");
    }
}

class SpadaMagica {
    private Attacco attacco;

    public SpadaMagica(Attacco attacco) {
        this.attacco = attacco;
    }

    void eseguiAttacco() {
        attacco.esegui();
    }
}

The Queen nodded.

“You have learned the principle. Never change what works, but extend it wisely.”

Third Proof: The Liskov Substitution Principle

Traveling through the Forest of Illusions, Refactor encountered an ethereal elf, the Third Oracle.

“Everything that replaces another must be able to be used without side effects. Show me that you understand this principle.”

A faulty code appeared:

class Pozione {
    void bevi() {
        System.out.println("Guarigione!");
    }
}

class PozioneVelenosa extends Pozione {
    void bevi() {
        throw new RuntimeException("Avvelenamento!");
    }
}

Refactor immediately noticed the problem and corrected the structure:

interface Bevibile {
    void consuma();
}

class Pozione implements Bevibile {
    public void consuma() {
        System.out.println("Guarigione!");
    }
}

class PozioneVelenosa implements Bevibile {
    public void consuma() {
        System.out.println("Avvelenamento!");
    }
}

The elf smiled, “Now the code can replace an instance without breaking the flow. You’ve learned well.”

Fourth Proof: The Interface Segregation Principle

Descending into the depths of the Forges of Creation, Refactor encountered a stout and stern-faced dwarf, the Fourth Oracle.

“Not everyone needs to know everything. Artifacts need to offer only what is needed by their users,” the dwarf said. “Now show me that you understand this truth.”

A confusing and overloaded code appeared in front of Refactor:

interface Strumento {
    void forgia();
    void scrivi();
}

class MartelloMagico implements Strumento {
    public void forgia() {
        System.out.println("Forgiatura completata.");
    }
    public void scrivi() {
        System.out.println("Errore: il martello non può scrivere!");
    }
}

Refactor quickly realized that a single interface could not accommodate tools with distinct functionality. I divided it into more specific interfaces:

interface Forgiatore {
    void forgia();
}

interface Scrittore {
    void scrivi();
}

class MartelloMagico implements Forgiatore {
    public void forgia() {
        System.out.println("Forgiatura completata.");
    }
}

class PiumaIncantata implements Scrittore {
    public void scrivi() {
        System.out.println("Scrittura magica completata.");
    }
}

The dwarf smiled smugly.

“You’ve learned that each tool should expose only the functionality its users need. Well done.”

Fifth Test: The Dependency Inversion Principle

On the Isle of the Void, suspended in the sky, Refactor met the last oracle, a knight in shining armor.

“You don’t build on fragile details. The foundation must be solid and general, so that what rests on it can remain solid. Show me that you know how to design a flexible system.”

Refactor examined the code presented to him:

class FiammaMagica {
    void accendi() {
        System.out.println("Fiamma accesa.");
    }
}

class Torcia {
    private FiammaMagica fiamma = new FiammaMagica();

    void illumina() {
        fiamma.accendi();
    }
}

Refactor realized that the flashlight was directly dependent on a concrete implementation, making the system rigid. He applied the dependency inversion principle:

interface FonteLuce {
    void accendi();
}

class FiammaMagica implements FonteLuce {
    public void accendi() {
        System.out.println("Fiamma accesa.");
    }
}

class Torcia {
    private FonteLuce fonteLuce;

    public Torcia(FonteLuce fonteLuce) {
        this.fonteLuce = fonteLuce;
    }

    void illumina() {
        fonteLuce.accendi();
    }
}

The knight nodded.

“Now the system can work with any light source, without depending on specific details. You understand the principle.”

The Defeat of Unravelor

Armed with his knowledge, Refactor returned to Artefatos and faced Unravelor. Using his newfound wisdom, he dismantled it piece by piece, separating its functions into specialized artifacts.

The kingdom was restored and Fastaroth was banished to the shadows.

“The harmony of the code leads to stability. Those who learn the principles of order will never again be threatened by chaos.”

Artefatos entered a new era of prosperity, and Refactor became the greatest wizard in the kingdom.--- This fantasy story illustrates SOLID principles, fundamental to creating robust and scalable software. Following them guarantees stability and growth over time.

And you? Have you defeated your Unravelor?