Greg Young [MVP] - All Comments

Long story short: Fixed price & Agile | Mission Control

Long story short: Fixed price & Agile | Mission Control — Sat, 13 Mar 2010 12:08:10 GMT

Pingback from Long story short: Fixed price & Agile | Mission Control

re: CQRS and Event Sourcing

Joe Balfantz — Fri, 12 Mar 2010 04:31:56 GMT

I'm warming up to CQRS and Event Sourcing (I nearly used a similar pattern two years ago), but I'm curious how you reconstitute a current snapshot of an object through an event log? Here's an explanation of my question: jbalfantz.wordpress.com/.../problem-with-event-sourcing-reconstituting-our-objects

re: State Pattern Misuse

DM — Wed, 10 Mar 2010 15:29:43 GMT

Thanks for the article Greg. I would also like to see the full solution if you get a chance to post it.

re: State Pattern Misuse

Remi Despres-Smyth — Wed, 10 Mar 2010 12:47:15 GMT

Greg,

Out of curiosity, can you give a scenario or two where you *would* use the state pattern then? Maybe it's just the type of problem I've had to work on, but I can't see many cases where you wouldn't need to throw in some states.

Isn't that the whole point of the pattern? Use state to help define the valid transitions between states - and if the invalid transitions don't throw, what do they do?

Regards,

Remi.

re: State Pattern Misuse

Tim — Wed, 10 Mar 2010 10:39:26 GMT

"its not like polymorphism would have worked before __anyway__."

There is no such word as 'anyways'.

dotNet News

Cadred (dotNET) — Tue, 09 Mar 2010 21:23:15 GMT

dotNet News

re: State Pattern Misuse

Sebastian — Tue, 09 Mar 2010 20:30:03 GMT

Hey Greg,

that's exactly what I've been asked the other day for a job interview. I was asked how to implement a machine of throwing out a chewing gum each time I put a coin in. The traditional response was to implement the State pattern exactly as you mention it (WithCoin) (WithouCoin) and you are right, there are behaviour that doesn't make sense at all for some state impl.

What does the method "throwOutChewingGum()" means in a "WithoutCoin" State? Obviously this perfect suites for throwing a runtime "NotImplementedYetException" other than business exception.

Well, in conclusion I gave roles to actors as ThrowOutMachine.throwOut(ThrowOutMachineContent, Money) where there're State validations in the "ThrowOutMachine <-> ThrowOutMachineContent" collaboration that replaces the State pattern purpose.

So I ask myself given your post, is State pattern really a good solution? Should be first look for a collaboration pattern such as Container - Content

Yeah, ppl always tend to open the GoF book... I don't know why, there's always a better solution using tradicional OO.

Cheers,

Sebastian.

re: State Pattern Misuse

Calum — Tue, 09 Mar 2010 20:16:41 GMT

hi,

Great article.

Could you post the full code for the solution? I would like to compare the bad code with the good code as I understand the theory but would like to see how it is done practically.

Thanks,

Calum

re: State Pattern Misuse

Sebastian — Tue, 09 Mar 2010 20:02:56 GMT

Hey Greg,

What does the method "throwOutChewingGum()" means in a "WithoutCoin" State? Obviously this perfect suites for throwing a runtime "NotImplementedYetException" other than business exception.

So I ask myself given your post, is State pattern really a good solution? Should be first look for a collaboration pattern such as Container - Content

Yeah, ppl always tend to open the GoF book... I don't know why, there's always a better solution using tradicional OO.

Cheers,

Sebastian.

re: State Pattern Misuse

Nick — Tue, 09 Mar 2010 16:34:52 GMT

So the Ubiquitous Language now speaks of 3 different Application classes as if they are separate? Conceptually, it's always a single Application, with a unique Id, no? I think it might be clearer to think of it as a single stateful object.

I agree State is wrongly applied here because in this case, all the implementations that just throw an exception aren't really valid operations, they should probably never be called.

In this case, I might rather just keep it to one class and do a check at the top of certain methods, throwing an exception if the method isn't allowed.

That way, you could keep it to

1. retrieve the application by id

2. perform the operation

3. save the changes

If the UI was implemented correctly, those exception throwing operations should never even be called, right?

re: State Pattern Misuse

Balaji — Tue, 09 Mar 2010 15:49:03 GMT

Canyou finish the example so that we can get the full taste of what you are saying

re: State Pattern Misuse

Phil B — Tue, 09 Mar 2010 15:11:36 GMT

In the past I've handled this by adding properties such as CanApprove, CanDeny, etc. It changes the client usage pattern so that they must check if an action can be done before attempting to execute it. This takes care of the LSP violation because the client code should expect an exception when it calls a method whose corresponding Can* property is false. I have always gotten a bit of a code smell from this solution though. You make some good points here.

re: State Pattern Misuse

Peter — Tue, 09 Mar 2010 13:49:52 GMT

I'm glad you included the code in all its gory LSP-violating detail. But I'm not sure I see what you're proposing as the alternative. Are the three classes derived from a common parent? If not, how are they consumed? What about common data for the application? Do you see an accompanying information holder for that stuff, e.g., LoanApplicationData?

re: State Pattern Misuse

Colin Jack — Tue, 09 Mar 2010 13:24:11 GMT

"Do some of the data/behavior only make sense in certain states? If so use three separate classes. Going along with this, if we find “throws” in our state implementors we should realize through LSP that we are doing something bad. "

Definitely agree it can be useful, but I do think its easily overused. Where there are a lot of states I've had success using separate classes each of which has 1 or more states.

On LSP, my view is its a LSP violation if a subclass breaks the contract by throwing an exception, if the exception is part of the contract of the base class then it isn't.

Interesting Finds: March 9, 2010

Jason Haley — Tue, 09 Mar 2010 12:35:37 GMT

Interesting Finds: March 9, 2010