Enterprise Integration Zone is brought to you in partnership with:

Kevin Rutherford, PhD, is a UK-based extreme programmer and agile software coach with over 30 years professional experience. He developed the Reek code-smell detector for Ruby and co-authored "Refactoring in Ruby". Kevin is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Simple Design with Design Patterns

  • submit to reddit
In the blog post Simple Design with Design Patterns, Cory Foy runs a thought experiment in which he explores the use of patterns in solving the Game of Life kata. Cory’s starting point is the intention behind the GoF patterns, coupled with the XP rules of Simple Design and Uncle Bob’s SOLID principles.

Cory stops his analysis when he has the following model:

|Cell| <------- |Status|
           |Alive|    |Dead|

At this point Cory says

“Certainly if we implemented a Cell with a Status object with an AliveStatus class and a DeadStatus class someone, somewhere, should slap us upside the head.”

However, I’d like to carry on from that point just a little further…

I like to teach the use of CRC for exploring design, and so I naturally looked at Cory’s objects from the point of view of their behaviours and responsibilities. Thus it struck me that if we don’t make the split suggested by Cory, we’d have a Cell that knows about its position/neighbours and knows what change to make when the clock ticks. That would violate the Single Responsibility Principle. So the above split into Cell and Status makes sense from the point of view of responsibilities, if we give the Status object the job of deciding how the Cell should change.

With those responsibilities in mind, a little mental CRC session suggests that, when the clock ticks, the Cell would tell its Status object how many neighbours it had, and ask for a new Status object in return.

Published at DZone with permission of Kevin Rutherford, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)