The Slay Log

public class SpellCaster {

    public void cast(String type, Caster caster, Target target) {
        switch (type) {
            case "fireball" -> {
                caster.spendMana(30);
                target.takeDamage(caster.intellect() * 2);
                target.ignite();
            }
            case "frost" -> {
                caster.spendMana(20);
                target.takeDamage(caster.intellect());
                target.slow(0.5);
            }
            case "heal" -> {
                caster.spendMana(25);
                target.restore(caster.intellect() * 3);
            }
            // ...200 more lines. A new spell? Edit this method.
            default -> throw new IllegalArgumentException(type);
        }
    }
}

public interface Spell {
    String name();
    void cast(Caster caster, Target target);
}

public class Fireball implements Spell {
    public String name() { return "fireball"; }

    public void cast(Caster caster, Target target) {
        caster.spendMana(30);
        target.takeDamage(caster.intellect() * 2);
        target.ignite();
    }
}

public class Spellbook {
    private final Map<String, Spell> spells;

    public Spellbook(List<Spell> known) {
        this.spells = known.stream()
                .collect(toMap(Spell::name, Function.identity()));
    }

    public Spell find(String name) {
        return Optional.ofNullable(spells.get(name))
                .orElseThrow(() -> new UnknownSpellException(name));
    }
}

public class SpellCaster {
    private final Spellbook spellbook;

    public SpellCaster(Spellbook spellbook) { this.spellbook = spellbook; }

    public void cast(String name, Caster caster, Target target) {
        spellbook.find(name).cast(caster, target);
    }
}

Open for extension means you can add new behavior. Closed for modification means you add it without editing code that already works and is already tested. The trick is a seam: an interface that stands for the thing that varies. Here the Spell interface is the seam, and every spell is one implementation of it. This is the Strategy pattern. Spell is the strategy interface, each spell is a concrete strategy, and SpellCaster is the context that uses whichever strategy it is given. Strategy is the usual way to reach Open/Closed, but not the only one: any polymorphism that replaces the switch does the same job. What this costs: an interface plus one small class per spell, and SpellCaster, which no longer changes. A Spellbook that maps names to spells is optional. SpellCaster can hold that map itself. It is only split out so lookup and casting each have one job. What you get back: a new spell is a new class and nothing existing is opened, so you cannot break fireball while adding frost. Each spell is tested alone. Three people can add three spells without touching the same file. When not to do it: with two or three spells that will never grow, the switch is simpler and perfectly fine. Add the seam when the same switch keeps being reopened, not before.

// --- The client: a duel that needs to cast spells ---------------------
public class Duel {

    private final SpellCaster spellCaster;

    public Duel(SpellCaster spellCaster) {
        this.spellCaster = spellCaster;
    }

    public void play(Caster wizard, Target troll) {
        spellCaster.cast("frost", wizard, troll);     // slows the troll
        spellCaster.cast("fireball", wizard, troll);  // burns it
        spellCaster.cast("heal", wizard, wizard);     // patches up the wizard
    }
}

// --- Composition root: the only place that knows every spell ----------
public class Game {

    public static void main(String[] args) {
        Spellbook spellbook = new Spellbook(List.of(
                new Fireball(),
                new Frost(),
                new Heal()));

        Duel duel = new Duel(new SpellCaster(spellbook));
        duel.play(new Wizard("Gandalf", 40), new Troll(120));
    }
}

// --- Later: the designer wants lightning. Add ONE class... ------------
public class LightningBolt implements Spell {

    public String name() { return "lightning"; }

    public void cast(Caster caster, Target target) {
        caster.spendMana(45);
        target.takeDamage(caster.intellect() * 3);
        target.stun(Duration.ofSeconds(2));
    }
}

// --- ...and ONE line in the composition root. Nothing else changes. ---
Spellbook spellbook = new Spellbook(List.of(
        new Fireball(),
        new Frost(),
        new Heal(),
        new LightningBolt()));   // <- the only edit

// Duel, SpellCaster, Spellbook, Fireball, Frost and Heal: untouched,
// retested by nobody, broken by nothing.
spellCaster.cast("lightning", wizard, troll);

// --- Casting a spell nobody has learned fails loudly, not silently ----
spellCaster.cast("meteor", wizard, troll);
// -> UnknownSpellException: meteor

public interface CharacterPort {
    Character loadCharacter(CharacterId id);
    void saveCharacter(Character character);
    void deleteCharacter(CharacterId id);
    List<Character> searchByGuild(GuildId guildId);
    List<Character> listLeaderboard(int top);
    String exportToJson(CharacterId id);
    // ...eight more methods
}

public class InventoryService {

    private final CharacterPort characters;

    public InventoryService(CharacterPort characters) {
        this.characters = characters;
    }

    public List<Item> itemsOf(CharacterId id) {
        // the ONLY thing this class ever calls:
        return characters.loadCharacter(id).items();
    }
}

// In the test: fourteen methods to stub, one of them used.
class FakeCharacterPort implements CharacterPort {
    public Character loadCharacter(CharacterId id) { return aCharacter(); }
    public void saveCharacter(Character c) { throw new UnsupportedOperationException(); }
    public void deleteCharacter(CharacterId id) { throw new UnsupportedOperationException(); }
    // ...eleven more that throw
}

public interface LoadCharacterPort {
    Character loadCharacter(CharacterId id);
}

public interface SaveCharacterPort {
    void saveCharacter(Character character);
}

public interface LeaderboardQueryPort {
    List<Character> listLeaderboard(int top);
}

// The adapter still does it all - it just promises each client less.
@Component
public class CharacterPersistenceAdapter
        implements LoadCharacterPort, SaveCharacterPort, LeaderboardQueryPort {
    // ...one class, one database, three small contracts
}

public class InventoryService {

    private final LoadCharacterPort characters;   // exactly what it needs

    public InventoryService(LoadCharacterPort characters) {
        this.characters = characters;
    }
}

// The test double is now a lambda:
LoadCharacterPort fake = id -> aCharacter();

Interface Segregation says: no client should be forced to depend on methods it does not use. Look at it from the caller's side, not the implementer's. In hexagonal architecture a port is the contract between a use case and the outside world. If one port serves every use case, each use case silently depends on everything the port can do. Change the leaderboard and the inventory screen is recompiled and retested for no reason. What it costs: more interfaces, and you have to decide where to cut. The adapter stays one class that implements several ports, so you do not get more infrastructure, only more names. What you get back: a service declares precisely what it needs, test doubles shrink from fourteen stubs to one lambda, and a change to one capability cannot ripple into services that never used it. Reads can even be split from writes, which is the first step towards CQRS. When not to do it: a port with three cohesive methods that every client uses together is fine. Split when different clients use different slices, not by default.

// --- Three clients, three different needs ----------------------------
public class InventoryService {
    private final LoadCharacterPort characters;

    public InventoryService(LoadCharacterPort characters) {
        this.characters = characters;
    }

    public List<Item> itemsOf(CharacterId id) {
        return characters.loadCharacter(id).items();
    }
}

public class LevelUpService {
    private final LoadCharacterPort load;
    private final SaveCharacterPort save;

    public LevelUpService(LoadCharacterPort load, SaveCharacterPort save) {
        this.load = load;
        this.save = save;
    }

    public void levelUp(CharacterId id) {
        Character hero = load.loadCharacter(id);
        hero.levelUp();
        save.saveCharacter(hero);
    }
}

public class LeaderboardPage {
    private final LeaderboardQueryPort leaderboard;

    public LeaderboardPage(LeaderboardQueryPort leaderboard) {
        this.leaderboard = leaderboard;
    }

    public List<Character> top10() {
        return leaderboard.listLeaderboard(10);
    }
}

// --- Wiring: Spring injects the SAME adapter into all three ------------
// CharacterPersistenceAdapter implements all three ports, so each
// constructor simply receives the adapter as the slice it asked for.

// --- Tests: only what the class under test uses ------------------------
@Test
void listsItemsOfACharacter() {
    LoadCharacterPort fake = id -> aCharacterWith(sword(), shield());

    var items = new InventoryService(fake).itemsOf(anId());

    assertEquals(2, items.size());
}

// --- Later: add a new capability --------------------------------------
public interface ExportCharacterPort {
    String exportToJson(CharacterId id);
}
// The adapter adds `implements ExportCharacterPort`. InventoryService,
// LevelUpService and LeaderboardPage never notice.