Kata: LegacySecurityManager in Java

This week I did the LegacySecurityManager kata in Java.

This is the original version of the code (ported from C# to Java):

	import java.io.BufferedReader;
	import java.io.IOException;
	import java.io.InputStreamReader;
	public class SecurityManager {
	public static void createUser() {
	BufferedReader buffer = new BufferedReader(new InputStreamReader(System.in));
	String username = null;
	String fullName = null;
	String password = null;
	String confirmPassword = null;
	try {
	System.out.println("Enter a username");
	username = buffer.readLine();
	System.out.println("Enter your full name");
	fullName = buffer.readLine();
	System.out.println("Enter your password");
	password = buffer.readLine();
	System.out.println("Re-enter your password");
	confirmPassword = buffer.readLine();
	} catch (IOException e) {
	e.printStackTrace();
	}
	if (!password.equals(confirmPassword)) {
	System.out.println("The passwords don't match");
	return;
	}
	if (password.length() < 8) {
	System.out.println("Password must be at least 8 characters in length");
	return;
	}
	// Encrypt the password (just reverse it, should be secure)
	String encryptedPassword = new StringBuilder(password).reverse().toString();
	System.out.println(
	String.format(
	"Saving Details for User (%s, %s, %s)\n",
	username,
	fullName,
	encryptedPassword)
	);
	}
	}

view raw SecurityManagerInitialVersion.java hosted with ❤ by GitHub

As you can see, createUser is a really hard to test static function which has too many responsibilities.

This is the final version of createUser after a "bit" of refactoring:

	import user_creation.*;
	public class SecurityManager {
	public static void createUser() {
	Console console = new RealConsole();
	new CreatingUser(
	new ConsoleUserDataRetrieval(console),
	new ConsoleReporter(console),
	new ReverseEncryption()
	).execute();
	}
	}

view raw SecurityManagerFinalVersion.java hosted with ❤ by GitHub

which is using the CreatingUser class:

	package user_creation;
	public class CreatingUser {
	private static final int MINIMUM_PASSWORD_LENGTH = 8;
	private static final String NOT_MATCHING_PASSWORDS_ERROR = "The passwords don't match";
	private static final String TOO_SHORT_PASSWORD_ERROR = "Password must be at least 8 characters in length";
	private final EncryptionAlgorithm encryptionAlgorithm;
	private UserDataRetrieval userDataRetrieval;
	private Reporter reporter;
	public CreatingUser(
	UserDataRetrieval userDataRetrieval,
	Reporter reporter,
	EncryptionAlgorithm encryptionAlgorithm
	) {
	this.userDataRetrieval = userDataRetrieval;
	this.reporter = reporter;
	this.encryptionAlgorithm = encryptionAlgorithm;
	}
	public void execute() {
	UserData userData = userDataRetrieval.invoke();
	if (!userData.passwordsMatch()) {
	reporter.reportError(NOT_MATCHING_PASSWORDS_ERROR);
	return;
	}
	if (isPasswordTooShort(userData)) {
	reporter.reportError(TOO_SHORT_PASSWORD_ERROR);
	return;
	}
	String encryptedPassword = encryptionAlgorithm.encrypt(userData.password());
	reporter.reportSuccessCreatingUser(
	composeMessage(userData, encryptedPassword)
	);
	}
	private boolean isPasswordTooShort(UserData userData) {
	return userData.passwordLength() < MINIMUM_PASSWORD_LENGTH;
	}
	private String composeMessage(UserData userData, String encryptedPassword) {
	return new UserCreationSuccessMessage(userData, encryptedPassword).compose();
	}
	}

view raw CreatingUser.java hosted with ❤ by GitHub

The before and after code is not so interesting as how we got there.

I kept the legacy code interface and tried to use as much as possible only automatic refactorings (mainly Replace Method with Method Object and Extract Method) to apply the extract and override dependency-breaking technique, from Michael Feather's Working Effectively with Legacy Code book, which enabled me to write tests for the code.

Then, with the tests in place, it was a matter of identifying and separating responsibilities and introducing some value objects. This separation allowed us to remove the scaffolding produced by the extract and override technique producing much simpler and easier to understand tests.

You can follow the process seeing all the commits (I committed changes after every refactoring step). There you'll be able to see there not only the process but my hesitations, mistakes and changes of mind as I learn more about the code during the process.

You can also find all the code on GitHub.

After reflecting on what I did I realized that I could have done less to get the same results by avoiding some tests that I later found out where redundant and deleted. I also need to improve my knowledge of IntelliJ automatic refactorings to improve my execution (that part you can't see in the commits).

All in all is a great kata to practice your refactoring skills.