Wednesday, February 8, 2012

Code Kata - Hidden Global States

I'm sure that most of you already know what a code kata is. For those who don't, you should already be googling about it.

I may not have mentioned this before, but we have started a set of sessions, seminars, talks, etc. at the company where I currently work at, aimed to improve our skills as programmers and the quality of our code base and products.

Everything is going well but as the 3rd conference on TDD and design principles was approaching, we started having the feeling that we need to get a little more technical about what we had discussed on previous sessions. You know what they say its easy to talk the talk.. but can you walk the walk...?

So, I decided to propose the idea of hosting this Code Katas every other week, so that we could touch more on the practical side of things. Which brings me to the subject of these post.

During some of the sessions, most of the examples where kind of textbook-like. Meaning that they got the point through, and where small and simple enough so that everyone could follow and understand them. However, most of the examples although illustrative were not real life situations, and we know how different real life can be...

So as I was looking for exercises that would allow us to practice on the subjects of the previous sessions which were about SOLID programming design principles and writing testable code, I did what anyone in my position would do, and started by googling for a few Katas that would suit my purpose.

However I was shocked at the lack of Katas touching refactorization of smelly production code. So, after a few unsuccessful attempts I decided to turn to the matrix of all problems and digging through some of the code base, I found some samples that where simple enough to use as Katas. I'm sure there are many more hidden smelly gems in there, and I will continue to post them in this blog as I find them. This is just the first of them.

The Kata
Suppose the following code is production code that has no tests. You must clean up the code as much as you can while at the same time ensuring that you don't break any of the functionality that is already depending on it. On the process ensure you end up with unit tests for the class that you are refactoring. 

The Objective
The objective of this kata is to practice decoupling of global states (singletons) and design for testability using advanced object oriented design principles.

The Code
package org.something.service;

public interface NumGenerator {
      public String generaNumSessio();
      public String generaReferenciaNotificacio();
      public String generaIdSolicitud();
package org.something.service;

import java.util.Calendar;
import org.springframework.stereotype.Service;
import org.something.service.NumGenerator;
import org.something.util.constants.NotificacionsConstants;

public class NumGeneratorImpl implements NumGenerator {

 public String generaNumSessio() {
  Calendar cal = Calendar.getInstance();
  return "SES"+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);
 public String generaReferenciaNotificacio() {
  Calendar cal = Calendar.getInstance();
  return "REF/NOTIFICACIO_"+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);
 public String generaIdSolicitud() {
  Calendar cal = Calendar.getInstance();
  return NotificacionsConstants.CAOC+cal.get(Calendar.MINUTE)+cal.get(Calendar.SECOND)+cal.get(Calendar.MILLISECOND)+"/"+cal.get(Calendar.DAY_OF_MONTH)+cal.get(Calendar.MONTH)+cal.get(Calendar.YEAR);

Happy coding! Let me know if this was helpful to you!

No comments:

Post a Comment