Ciao.

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.

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