Stateless
Posted by Nicholas Blumhardt | July 27, 2008 18:13
Our team recently needed to add fairly complex lifecycle to a couple of domain objects.
Simple State Machine looked to fit the bill very nicely, but we ended up going with an even simpler implementation in C# only (SSM uses a Boo e-DSL.)
The results were very usable, but the implementation well, wasn't the nicest piece of code I'd written. Sleeplessness motivated me to take another shot at the problem, and the result is now on Google Code awating your scathing criticism :)
BTW, yes, the title of the project is irony. My sense of humour really is that bad.
Comments
Your Comment
Disclaimer: These articles represent the opinions of the authors and may not match the official position of Ubik Systems Pty. Ltd. Confirmation should be sought on all matters involving professional advice.
Posted by Nick | July 27, 2008 08:25
Incidentally, exposing a State or Status property on a domain object is a bad breach of encapsulation, even when the status value is behind a property accessor. In the phone call example, I would once have considered exposed something like Status on my PhoneCall domain object. Using boolean properties like IsInCall is better because you can vary the semantics of the status values. IsInCall can keep up when more substates of the Connected state crop up (e.g. OnHold) while code reliant upon status (phone.Status == State.Connected) will break. Designs that are created test-first will probably tend in this direction anyway, because at the outset there won't be a Status enumeration to use anyway.