Part 5: Rear-view mirror.So it's the end of the flashback.. for anyone who lasted this far. I've the design all coded out and it works. So let's have a look at the design that we ended up with. Might be a good side-by-side compare with the first post in this series.
Final touch-ups that I did,
- renamed SensorObserver to ObservableCoffeeMakerDevice.. long name but it is an internal class so there.
- Also I renamed some event-handler in CoffeeMaker in the name of readability and all that is good. On_WarmerPlateStatusChangedAfterBrew >> TurnIndicatorLightOn_AsSoonAsThereIsFreshCoffee.
These are the Object cubes (flattened) for the final set of classes. Contrast with the objects in Post 1. So what did I learn?
- A little DUF helped cut down the number of classes I started off with.. Sketching them out on paper, helped me filter out lazy classes. I think I did JED here.. Just enough design to get moving.. good move.
- I'm a little sloppy / not thorough with my TDD; I missed out some tests and then went out of my way to add them as and when I remembered. Maybe spending some time to list out all the tests.. just the test-method names as empty stubs could be a counter-measure
- Felt uneasy for a while while I was building a SensorObserver component (in full) one test at a time without completing any user-stories. Maybe I should have implemented just enough of SensorObserver to implement a story#1..
- I conveniently forgot about the Brew Button in my initial design sketches.. However it didn't prove to be a big time-sink of a omission.
- A major chunk of my time was spent debugging a multi-threaded issue. TDD didn't help..Console.WriteLines saved the day. After that it was smooth sailing.
- Object Cubes aid in thinking about design.. I'm definitely adding this to my toolkit (Although I could do without Side 3.. A simple + (public) and -(private) before the method name helped me depict the public and private contracts)
- Object Thinking the book shunned "controller" classes. I couldn't think of a way to come up with a CoffeeMaker design that doesn't control the device via the exposed API.
- This is a very nice OOD problem.. deceivingly simple at first sight..worth burning some brain cells on. Now I need to finish the rest of UncleBob's APPnP book.
Want the 69kb source code zip (built onVS2008 Express Edition)?.. drop me a mail at gishu[dot]pillai[at]gmail[dot]com or let me know of an easy way to place this zip on an online shelf.