Extreme Enthusiasm

  @Test public void gutterGame() throws Exception {
    BowlingGame game = new BowlingGameFactory().create();
    for (int i=0; i<20; i++) {
      game.roll(0);
    }
    assertEquals(0, game.score());
  }

  class BowlingGameFactory {
    public BowlingGame create() {
      return new BowlingGame();
    }
  }

  class BowlingGame {
    public void roll(int n) {}
    public int score() {
      return 0;
    }
  }

  @Test public void allOnesGame() throws Exception {
    BowlingGame game = new BowlingGameFactory().create();
    for (int i=0; i<20; i++) {
      game.roll(1);
    }
    assertEquals(20, game.score());
  }

  interface Rolls {
    void add(int n);
    int sum();
  }

  class BowlingGame {
    private final Rolls rolls;

    public BowlingGame(Rolls rolls) {
      this.rolls = rolls;
    }

    public void roll(int n) {
      rolls.add(n);
    }

    public int score() {
      return rolls.sum();
    }
  }

  class BowlingGameFactory {
    public BowlingGame create() {
      Rolls zero = new Rolls() {
        public void add(int n) {}
        public int sum() { return 0; }
      };
      return new BowlingGame(zero);
    }
  }

  class Accumulator implements Rolls {
    void add(int n) { ... }
    int sum() { ... }
  }

  class BowlingGameFactory {
    public BowlingGame create() {
      return new BowlingGame(new Accumulator());
    }
  }

6 Responses to “The OCP kata”

1. Franco Lombardo Says:
   January 15th, 2010 at 10:10

   Matteo,

   good exercise: we must do it at XP UG Milan! :-)

   Now some notes. You say
   “1. compose functionality out of existing objects”: that’s OK.

   “2. avoid reworking existing code”: please, could you explain this? I mean, in your example, at each step you do need to modify some part of the existing code: the BowlingGameFactory, the BowlingGame…
   To be honest, in the Open Close Principle what I don’t believe in is the “Close” part. Meyer, in it’s original book, thought to implement it mainly via inheritance. But, as in the beginning of your post, “favor composition over inheritance” it’s a good rule!
   To use composition, you must have designed some “injection” point for new behaviors: in your example, the Rolls interface could contain new behaviors, but you need to modify all your classes to accept this injection. Now your code is “closed” to change in this direction, but as soon as new change directions will arise, probably you will need to rework the existing codebase.

   Thanks

   Bye

   Franco

2. matteo Says:
   January 18th, 2010 at 19:19

   Hi Franco, thanks for your feedback :)

   First let me say that this is an exercise, and it’s focused on one single aspect of OOD, namely the OCP. I’m not saying we should work like this all the time :-)

   Now, let me clarify the “not reworking” thing. In an ideal world, I should be able to accept a new requirement by creating a new class, and injecting it in the system by changing the “main” or the “factory” of the system. It would be even better if I could add new behaviour simply by configuring and instantiating existing objects.

   For instance, take the bowling example. If you have all your scoring rules in a chain of responsibility, you could add the “strike” scoring rule by creating a new StrikeScoreRule class and injecting the object in the system:

   BowlingGame create() {
   Rolls rolls = new Rolls();
   List rules = Arrays.asList(
   new StrikeRule(rolls),
   new SpareRule(rolls),
   new SumOfTwoRollsRule(rolls));

   return new BowlingGame(rolls, rules);
   }

   Suppose now that they ask you to implement “Martian Bowling”, where you have a maximum of three rolls per frame. You might implement it by creating a SumOfThreeRolls class, and changing the factory like this:

   BowlingGame create() {
   Rolls rolls = new Rolls();
   List rules = Arrays.asList(
   new StrikeRule(rolls),
   new SpareRule(rolls),
   new SumOfThreeRollsRule(rolls));

   return new BowlingGame(rolls, rules);
   }

   or you might have a flexible object that can act as both the SumOfTwoRollsRule or the SumOfThreeRollsRule like this:

   BowlingGame create() {
   Rolls rolls = new Rolls();
   List rules = Arrays.asList(
   new StrikeRule(rolls),
   new SpareRule(rolls),
   new SumOfSomeRollsRule(3, rolls));

   return new BowlingGame(rolls, rules);
   }

   Now you ask, what if I am not living in an ideal world, and I cannot simply add new behaviour without reworking everything? And this is the common case! In my opinion, what you could do then is to first refactor everything *as if* you had foreseen the new requirement. You refactor until you can apply the OCP. Then you insert the new requirement, and it just “slides in” like magic.

   I think it’s even better to wait until you have an actual requirement, before you make everything super-flexible. Otherwise you run the risk of making everything too flexible, that is, to over-engineer.

3. Giordano Scalzo's Personal Blog » Milano XpUg January Coding Dojo Says:
   February 6th, 2010 at 16:16

   [...] As introduction I prepared a little presentation, mainly with the aim to clarify the “Ocp Way” to do katas, as conceived by Matteo Vaccari in his blog: XpUg Coding Dojo: KataYahtzee in [...]

4. 84° Extreme Programming User Group di Milano | Geek Agenda Says:
   February 21st, 2010 at 15:15

   [...] Randori: a coppie ci si alternerà al proiettore per risolvere un semplice problema, in modalità OCP; non è obbligatorio partecipare alla coding session,ma si può semplicemente assistere allo [...]

5. Extreme Enthusiasm » Blog Archive » Report of the first run of the OCP kata Says:
   February 23rd, 2010 at 21:21

   [...] prepared such a good presentation mentioning, among other things, the “OCP Kata” of my earlier blog post. The “Open Closed Principle” says that we should be able to add new feature by adding [...]

6. Tonyx Says:
   March 2nd, 2010 at 1:01

   Ciao Matteo,
   there is an implementation in c#:
   http://github.com/tonyx/katabowling

   Ciao.

Leave a Reply