jamesladdcode.com

Gregor Gramlich presents his view on East here.

Recently I found that my East paper was blogged about elsewhere and of course I’m flattered. So I dug around a bit and found some comments suggesting that the code in the examples was not very readable, and while I find that debatable I think it is important to give a simpler example, one that is as simple as I can make it, along with another revision of the principles/rules of East Oriented code.

Principles/Rules:

1. All public methods should be void, boolean or return a reference to the current object (this in Java).
2. Objects that implement the Factory or Builder pattern or similar are an exception.
3. East is better suited to composite objects, not primitive objects. Personally I don’t make this distinction.

An Example:

Imagine we have a Customer class and we want to send a present to the Customer on their birthday, flowers for a girl and cufflinks for a boy. In a typical non-East and very non-Object Oriented way (in my opinion) your object could look like this:

class NotOOCustomer {

  public Sex getSex() {}

  public Date getDateOfBirth() {}

}

Now we change it to be East and Object Oriented:

class EastOOCustomer {

  public boolean isMale() {}

  public boolean isBirthday(Date today) {}

}

I’m hoping that this example is simple and readable?

Now if you try writing the code to send the flowers or the cufflinks using first the NotOOCustomer class and then the EastOOCustomer class you will see a big difference between the two. When done, change the internal representation of gender and the date of birth in each version and see the impact on your code. For the full experience and magic try to use Test Driven Development.

What should happen is this:

1. You wrote less code using the East Object Oriented Customer class.
2. You had a smaller change impact when changing the internal representation of gender and date of birth.

I’m keen to hear your feedback and see your examples for both cases. Please drop me a line.