Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> Comments on: Don’t Give Up on the State Pattern Just Yet http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/?utm_source=rss&utm_medium=rss&utm_campaign=dont-give-up-on-the-state-pattern-just-yet Tue, 08 May 2012 09:13:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Churriment http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-64375 Churriment Tue, 25 Oct 2011 00:57:00 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-64375 false == CanWithdraw()what? false == CanWithdraw()what?

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-2/#comment-55380 Jan Van Ryswyck Fri, 02 Apr 2010 05:35:44 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55380 @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well. @Greg: In my follow-up post I talked about how to mitigate the checking part when using role interfaces. You can remove the polymorphism in the same way using a DynamicObject. As I said, I totally agree with your post and the misuse of any design pattern for that matter. Everything has it advantages and disadvantages and the downside is indeed coupling. But I think there are valid scenarios for using the State pattern as well.

]]> By: Greg Young http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-55177 Greg Young Thu, 01 Apr 2010 12:20:50 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-55177 I think a bit of what I was posting about was missed. My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism ... I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism ... why? There is a big downside to it in terms of coupling. Greg I think a bit of what I was posting about was missed.

My issue is not with the state pattern per se though it can get ugly. it is more so with people misusing the state pattern. In my example there would be nothing in common between the 3 versions :) it would be throws laced through much of the implementations. Even if we went to role interfaces we would end up with tons of code checking things. Beyond that there isnt any real use case that would actually be using the polymorphism … I find it to be quite a trend that people like to make things polymorphic even if they dont actually use the polymorphism … why? There is a big downside to it in terms of coupling.

Greg

]]> By: Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54708 Elegant Code » Don’t Give Up on the State Pattern Just Yet – Revisited Sat, 27 Mar 2010 00:05:28 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54708 [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...] [...] my previous post on the subject, I showed how you can remove some of the friction caused by applying the State [...]

]]> By: Szymon Kulec http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54653 Szymon Kulec Mon, 22 Mar 2010 13:20:59 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54653 I hope I understand your usage of explicit interfaces in this case, but wouldn't it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea? Btw. I do like Greg's proposal, cause the unusual cases are the majority of cases in this state pattern example. I hope I understand your usage of explicit interfaces in this case, but wouldn’t it be possible to change all the interfaces to TryDo____ methods? No checks for implementing interfaces, no need to throw exceptions, all to do: returning true after any positive processing or no processing at all. What do you think about this idea?

Btw. I do like Greg’s proposal, cause the unusual cases are the majority of cases in this state pattern example.

]]> By: The Morning Brew - Chris Alcock » The Morning Brew #564 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54645 The Morning Brew - Chris Alcock » The Morning Brew #564 Mon, 22 Mar 2010 08:44:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54645 [...] Don’t Give Up on the State Pattern Just Yet - Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...] [...] Don’t Give Up on the State Pattern Just Yet – Jan Van Ryswyck follows on from Greg Young’s post on the state pattern last week with a look at using interfaces to control what state transition are possible for an object [...]

]]> By: Steve Py http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54638 Steve Py Sun, 21 Mar 2010 22:37:45 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54638 The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though. The issue with approaches like this is that you need to do a lot of type-checking and casting throughout the code for each applicable interface. Interfaces like that are good for simplifying cases where you need to pass an IDepostable etc. to a given object/service though.

]]> By: Julian Birch http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54627 Julian Birch Sun, 21 Mar 2010 16:46:11 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54627 I've got to admit, I'm quite fond of the classic state pattern implementation. Implementing all of those methods where you can't do anything may be a pain, but you end up putting in explicit feedback about why they can't be done. I’ve got to admit, I’m quite fond of the classic state pattern implementation. Implementing all of those methods where you can’t do anything may be a pain, but you end up putting in explicit feedback about why they can’t be done.

]]> By: Jeff Doolittle http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54614 Jeff Doolittle Sun, 21 Mar 2010 05:11:18 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54614 @Jan - yeah, I can see what you mean. I can think of a few other examples I've seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern. @Jan – yeah, I can see what you mean. I can think of a few other examples I’ve seen where the state pattern implementation contains ISP violations. I think your approach certainly helps redeem the pattern.

]]> By: Jan Van Ryswyck http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/comment-page-1/#comment-54609 Jan Van Ryswyck Sat, 20 Mar 2010 19:07:46 +0000 http://elegantcode.com/2010/03/19/dont-give-up-on-the-state-pattern-just-yet/#comment-54609 @Rob G The recursion is indeed not the best thing since sliced bread. The original GOF example shows this as well. @Jeff Doolittle: I agree, but this seems to be how its mostly used. The original example (TCPState) in the GOF book has the same ISP violation as well. @Rob G The recursion is indeed not the best thing since sliced bread. The original GOF example shows this as well.

@Jeff Doolittle: I agree, but this seems to be how its mostly used. The original example (TCPState) in the GOF book has the same ISP violation as well.

]]>