Recently there has been some interest in my East approach to software development both in the post here in my blog and in the Test Driven Design group on Yahoo. Michael Feathers of Object Mentor fame even said “East Bound code, a brilliant new way of looking at ‘Tell, Don’t Ask’:”
There have been some great questions about East and a call for more examples so I’m adding another here with this post. The example is a simpler one intended to show an East approach without the clutter of anonymous inner classes (that can be a bit of a pain in Java). There is a README in the download and the Test classes are also included to add weight to my claim that East code is easier to test, since it can focus on interaction and state at the same time, and because the classes are smaller and more reusable. If you download the example code then please read the README.
I also wanted to expand and clarify the rules for going East. East Oriented code follows the following rule:
- All public methods are void or they return this/self or a boolean value.
I have been asked when should this rule be applied and my response is:
- Always for composite classes but not for simple classes like String, or Integer unless it fits.
The result of an East approach is a system where there are more classes but those classes are simpler and they have a single responsibility. The likelihood of being able to reuse of combine classes to do more is greatly increased. For example, look at the new example code and see how you could add a CustomerPrinter that can both format a customer salutation and combine this with a CustomerXmlPrinter to output that salutation in XML by reusing a combinator class and not writing more code.
It is one rule that yields a surprising results in your code, so please try it out regardless of what language you code in.
If you would like some help then drop me a line.
* This image is by Ben Ryan (http://www.istockphoto.com/cannboys) - I hope you also like and use his work.