The OCP kata
Read the first chapter of the Patterns book, it’s all there, where it says “favor composition over inheritance”,
said Jacopo. We were chatting about the Open/Closed Principle, and how I read about it in Meyer in 1991, yet it didn’t “click” for me back then.
Now I see how the OCP is key to writing code that can be changed easily, which is the chief technical goal of an agile team. I wondered, is there a way to teach and learn the OCP? Is there a kata to learn OCP?
It’s unfortunate that most common coding katas result in “single-object-oriented programming”. The famous bowling score example by Robert Martin, for instance, is usually solved by creating *one* object. This might be fine for learning how to write simple code. It’s not so good for learning how to do object-oriented design.
So I invented this little exercise to practice and learn OCP.
Take any coding problem. The bowling score, the string evaluator, the supermarket checkout, you name it. Then follow these instructions.
0. Write the first failing test. Then write a factory that returns an object, or an aggregate of objects, that make the test pass.
The factory should be limited to creating objects and linking them together. No conditionals allowed.
1. Write the next failing test.
2. Can you make it pass by changing the factory and/or creating a new class and nothing else? If yes, great! Go back to 1. If not, refactor until you can.
The refactoring should bring the system to a state where it’s possible to implement the next test just by changing the aggregate of objects that is returned by the factory. Be careful not to implement new functionality; the current test should still fail.
For instance, take the bowling score problem. The first test is
@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());
}
The code to make this pass is
class BowlingGameFactory {
public BowlingGame create() {
return new BowlingGame();
}
}
class BowlingGame {
public void roll(int n) {}
public int score() {
return 0;
}
}
Nothing strange here. Now the second test is
@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());
}
The simplest code that makes both tests pass would be to change BowlingGame to accumulate rolls in a variable. But our rules stop us from doing that; we must find a way to implement the new functionality with a new object. I think about it for a few minutes, and all I can think of is to delegate to another object the accumulation of rolls. I will call this role “Rolls”. Cool! This forces me to invent a new design idea. But I must be careful not to add new functionality, so I will just write a Rolls object that always returns 0.
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);
}
}
This passes the first test, and still fails the second. In order to pass the second test, all I have to do is provide a real implementation of Rolls and change the factory.
class Accumulator implements Rolls {
void add(int n) { ... }
int sum() { ... }
}
class BowlingGameFactory {
public BowlingGame create() {
return new BowlingGame(new Accumulator());
}
}
And so on. The point here is to think about how to
- compose functionality out of existing objects, and
- avoid reworking existing code.
Feedback?
Updates
24/12/2013 Chris F Carroll‘s Gilded Mall Kata is a new exercise that can be done with the OCP kata rules. Thanks Chris!
29/05/2014 There is now a repository with a few prepared exercises! I presented this at XP2014.
January 15th, 2010 at 10:06
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
January 18th, 2010 at 19:32
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() { rules = Arrays.asList(
Rolls rolls = new Rolls();
List
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() { rules = Arrays.asList(
Rolls rolls = new Rolls();
List
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() { rules = Arrays.asList(
Rolls rolls = new Rolls();
List
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.
February 6th, 2010 at 16:06
[…] 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 […]
February 21st, 2010 at 15:51
[…] 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 […]
February 23rd, 2010 at 21:49
[…] 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 […]
March 2nd, 2010 at 01:24
Ciao Matteo,
there is an implementation in c#:
http://github.com/tonyx/katabowling
Ciao.
July 12th, 2010 at 17:19
[…] kata was meant to be executed with the OCP Dojo rules. I will use Ruby today, because I want to take a break from Java. But the solution will not […]
October 7th, 2010 at 09:49
[…] I have not become convinced that iterative development, small steps, refactoring are to be avoided. I’m not advocating doing some big upfront design to make sure we can hit the release code without iterating, without incrementing functionality bit by bit, without refactoring. I still think that iterative and incremental design is the only reliable way to produce good software. But we must remember that refactoring per se is waste. Francesco Cirillo is fond of saying that emergent design is not “doing some messy work now, then I will refactor”. It’s more efficient to write incremental code that can be extended without refactoring; it’s more efficient to exploit the Open-Closed Principle! […]
November 6th, 2010 at 23:34
[…] Days Benelux, November 25. Together with Antonio Carpentieri I will present a workshop on the Open-Closed Principle Dojo. It’s a way to learn an important principle of object-oriented […]
November 10th, 2010 at 13:41
[…] Extreme Enthusiasm » Blog Archive » The OCP kata. Pagine […]
November 23rd, 2010 at 17:30
[…] dell'XP User Group di Bergamo abbiamo provato a rifare il Kata "Sasso-forbici-carta" seguendo le regole "Aperto-chiuso" suggerite da Matteo Vaccari. Il pubblico non era certo numeroso…ehm…ehm…vabbe', se vi interessa qui sono le slides e […]
March 22nd, 2011 at 11:27
[…] In December me and Matteo Vaccari have presented the The Open-Closed Principle Dojo based on his OCP Kata. […]
March 16th, 2014 at 19:34
[…] Just playing with Open Closed principle Share this:TwitterFacebookMi piace:Mi piace Caricamento… […]
April 24th, 2014 at 13:00
[…] the open to extension and closed to modification, we’re going to follow the workflow described at http://matteo.vaccari.name/blog/archives/293. This is how it […]
June 27th, 2016 at 23:26
Follow to the conversation on twitter https://twitter.com/xpmatteo/status/747305326618148864
Say I have implemented the normal accumulating bowling score and I write a test for strike.
It seems that making the test pass with a conditional like this is contrary to the rules.
if (rolls[0] === 10) {
score = sumOf3Rolls(rolls)
} else {
score = sumOf2Rolls(rolls)
}
However if I refactor right after the result is (probably) the same. And to me there are several advantages to this “refactor after” approach.
The advantages of “refactor after” are to me
– compliant to Make it work then Make it good
– easier (ok that’s a bad argument for a kata)
– builds a habit of looking at manifest mess before refactoring -> likely to lead to simpler design
So my question is what will people gain from doing it in the “refactor before” way? I tried it for quite a bit, didn’t get much from it but I suspect I might be missing something here.
June 28th, 2016 at 10:45
The “refactor before” rule of the OCP Dojo is a trick, to force the learner to think about why a certain extension of behaviour is not possible with the current code. This dojo is all about pushing the abstraction pedal as far as possible. Someone said that the only way to know when something is “too much”, is to do it too much!
So yes, in Real Work sometimes you complicate the code a bit, and then refactor. Some other times, when you find that implementing something is difficult, you first make it easier by refactoring (which might be difficult to do), and then you do it.
In a dojo context, however, if the goal is to practice creating abstractions, the rule about creating it before use is meant to force a behaviour. If you intend to create it after, you run the risk of rushing to making the next test pass, and forget to introduce the abstraction at all. So I think it can be OK to be flexible about introducing the abstraction after you need it, as long as you have a watchful moderator that will remind the learners to implement the abstractions!
Is that any clearer? I mean, the exercise is meant to help people who aren’t used to creating abstractions. If your audience has the opposite problem, then you might do better with another exercise, like e.g., the TDD As If You Meant It by Keith Braithwaite
June 28th, 2016 at 12:07
Your answer is clear. I’ll try more times for my own benefit. I also project using this dojos in training teams, and I’m much more hesitant. I do see there’s probably and muscle training that is a bit different and perhaps more acute. The possible downsides to me as a training tool are
– Few people allow themselves to write shitty code first, and it is such an efficient design tool. This is for instance a major difficulty in learning TDD – allowing yourself to just make the test pass, and quickly
– I want them to have a tool that is readily available immediately (well mostly) and the ability to refactor “after” towards OCP is easier to learn.
Maybe which approach is best depends on the person doing it, so “refactor before” could be an optional constraint. The base constraint being to refactor before next test.