This week while working on my echo server I had a chat with one of my mentors about the design approach that I was taking my program.

Here is my Echo Server requirements

  • Start program
  • prompt user to type something
  • Type "hello<return>"
  • Program responds with "Hello\n"
  • Type "exit<return>"
  • Program terminates

Test Driven (naturally)
100% test coverage (outside of Main)
No use of dynamic mocking frameworks
I had two components that I knew I had to implement. A EchoServer, which is responsible for running a server and delegates the input and output elsewhere. A echo console which was responsible for input and output. Hope you notice that glaring bad "and" in the previous sentence, console is in a clear violation of the Single Responsibility Principle (we will come back to that).

We usually start solving our problem by dividing our problem into sub problems, which raises the question......where do we start, the top or the bottom? We can look at the problem from the top, that's to say, I have this problem of echoing back what the user types in, I need to do the following to fix it.

Something to alert the user to enter information.
Something to handle the input
Something to print the output
Something that has a loop and will only quit when user types exit

That's a lot of somethings.

We need to delve deeper so we can uncover what something is, is it a method/class/variable etc.
As we slowly delve deeper and deeper, our program will begin to unfold, until we have a finished working program.

I particular like this approach as it gives me a clearer idea on what are the required modules and submodules of the system or maybe I like this way because it's how I've traditionally approached implementation, not necessarily the best way but what I've felt comfortable. Will have to do the bottom up approach to push myself.
I will talk about bottom-up design in part 2

Ced

Ced