first coding dojo I hosted the whole team just before the Christmas break. So I prepared some cookies, and some hot wine punch and invited everyone to help our friend Santa Claus!
Santa gets to work when we all try to spend some quality time with our families: on Christmas Eve.
His work is always the same:
- Santa has to think of some nice gifts from Smriti.
- Santa has to choose one of his many ideas at random.
- Santa has to buy that gift from the mall.
- Santa has to deliver that gift by car.
I gave the teams (pairs of two) a brief glimpse of Santa’s mind:
The teams now had about 15 minutes to code up a console application that plots the following output:
Console output is not very convenient. As soon as Santa closes the application, all information is lost.
So as the only client of our application he wants the output to be written to a file. He wants to toggle that functionality via command line argument.
The teams had another 15 minutes to implement that feature.
Some teams already discussed their architecture heavily, some teams took very practical approach, some teams consciously went completely quick and dirty. So many different solutions for such a small task.
And not the first time! Of course this affects Christmas Eve:
When he is drunk, Santa does not remember presents from memory. He has to get his thoughts from a file he created when he was sober:
Since we never know whether Santa would be drunk or sober on Christmas Eve, the team was instructed to create another command line argument to toggle that behavior: from memory, when sober, from the drunk file. .
The teams had 15 more minutes.
Deserializing the *.json file was a piece of cake. But the development of some teams had already slowed down a bit. The quick and dirty team in particular had to fight with their own design decisions.
Each team moved a laptop to the right and left with their predecessors’ codes. It was like being the new guy on the team and looking at a big pile of legacy code.
They now had to implement the following new requirements in 25 minutes:
when santa is drunk
- he does not care. He always chooses the first gift he finds on file.
- He cannot go to the mall. He only orders from Amazon.
- He can’t (and isn’t allowed to) drive a car! He just rides his reindeer. old school.
This is how the output should look afterwards:
All teams immediately had a negative attitude towards the new code base. Simply because it was unknown and has yet to be read and understood. A colleague of mine also said that looking at the quick and dirty excerpt’s code:
I think we should continue to apply in that style…
This illustrates one of the main problems of code smells: they are contagious. The prohibition level of writing bad code drops when you go inside smelly code. The whole solution becomes more and more messy. it is also known as broken windows theory,
All the teams admit that the practice was not easy, however trivial it may seem. I asked him if any of his solutions followed these rules? open-close-principle: Nobody did.
So I presented them a solution that does. Thanks for the strategy pattern.
take a look at the method
Run() , It is very easy to read. It represents our algorithm, our strategy. Santa does this process every year, whether drunk or sober. And the best part: This method remains untouched:
- Santa has to get his thoughts by any means
- Santa has to decide somehow
- santa has to buy a gift from someone
- Santa has to be accompanied by a gift of any kind
The strategy is very abstract. And that’s the key part of this pattern:
- The strategy doesn’t care whether the thoughts come from memory, a file, the Internet, or its friends. it just needs method
- The strategy doesn’t care whether Santa chooses randomly, the first or last gift. it just needs method
Present ChooseFrom(IEnumerable<Present> presents)From
- The strategy doesn’t care whether Santa buys the present at the mall, orders it from Amazon, from eBay, or if he tinkers with it himself. it just needs method
void Buy(Present present)From
- Strategy doesn’t care if Santa saves by car, by reindeer, on foot, or with a little help from UPS. it just needs method
What happens on Christmas Eve always remains the same. Only how it is done varies from time to time.
Everything remains the same as our strategy. it’s inside our classroom
Anything that can change is injected into the class as a dependency through the constructor.
This way we can decide how the strategy is executed, simply by injecting the desired implementation.
That’s all. That’s the strategy pattern.
Short and fast! Here are two examples:
- We create a new class, like
- we implement that class
- we give
ChristmasEvean example of
- That’s it. We didn’t touch any old code. We just added new code. open-close-principle approves.
It’s about identifying the strategy.
- What do you want to do? – Write things down!
- Where do you want to write things? – I do not care. I just want to write.
- Conclusion: We only need one interface
IOutputwith the same method
This is how the two implementations might look. Both are small and fast. You see what the classes do without scrolling.
Here’s what our application root might look like:
I really like the solution. Strategy pattern really works well for this problem. All classes are short and readable. We have the flexibility to easily react to further changes.
Christmas saved! Thanks for the help!
Somewhere it has to be done. At least that way it’s in one place. You can swap behaviors right here inside the root of your application, instead of digging through the whole application.
And some smart people have already solved that problem for you. If your root really gets too big to handle it might be time to look into IoC-containers like autofac,
Have you ever hosted a coding dojo? How were your experiences? Tell me! ,
Thanks for reading!
#Learn #Strategy #Pattern #simple #exercise #Materials #Cello #August