Methods should tell a story.

Before completing my echo server, my mentor noticed that I wasn't using test doubles effectively. He suggested that I do spike of the echo server to get a better idea how the final implementation would look like.

Once I had completed the spike, I was happy with the start method initially but since completing it again using TDD and with the use of my private methods, the start method is looking a lot clean.

Exhibit A

public void Start() {

string message = "";

PromptUser();
while (IsExitCode(message)) {
output.Write(message + "\n");
}
}

Exhibit B

public void Start() {
PrintWelcomeMessage();
while (true) {
ReadUserInput();
ReadSpecialCaseInput();
if (CheckIfExitInput())
break;
Echo(input);
}
}

Not only was Exhibit A in fact hiding some side effects in the private methods ( looking at your isExitCode) it wasn't telling a story the way Exhibit B, tells a story. Exhibit B has aa nicer flow because each method name is descriptive about it's execution.

Methods should be short as possible and tell a story and not only this, it makes it easier to unit test behaviour.

Ced

Ced