His point is that no counter-example is needed. The solution in which the client/caller/user simply passes in the desired Churner behaviour to the churn method is as simple as it gets. Otherwise, the caller would still need to call the provideAdapter somewhere.
In the Java world there is a saying: You can always count on an architect to provide another level of indirection (to not really solve not really a problem).
Well....
Posted byandrewat
2006-09-08 11:01 AM
In this case, any time I wanted to change the passed in behavior: SimpleChurner - I would have to change all the callers. What if I want the added features a DeluxChurner provides, because it churns more efficiently? The win (in my experience) is that, I do not have to change any existing code, but simply change the registration for the adapter and the callers get this change for free.
The example Chris provides is simple, in more complex systems I find this pattern dramitcally decreases the amount of code requiring change. To say, "In the Java world there is a saying: You can always count on an architect to provide another level of indirection (to not really solve not really a problem)." is an irrelevant association. The problem that this added indirection solves is that we do not have to change code. Callers do not need modifying, all that has to change is the registration (done in configuration in the case of Zope).
sure?
Posted bychrismat
2006-09-08 01:18 PM
""" His point is that no counter-example is needed. The solution in which the client/caller/user simply passes in the desired Churner behaviour to the churn method is as simple as it gets. """
Fredrik didn't suggest we pass in a Churner to the churn method. He suggested we use a superclass with a template method (a different GoF design pattern). A subclass would provide a method that returns a particular kind of churner, which would be called by the superclass "churn" method. And that's fine; it solves the example problem I proposed nicely. It does fail to solve the case of wanting to adapt something to something else when neither one of those things are "self", though. Nothing in the example code requires this, but it does happen.
""" Otherwise, the caller would still need to call the provideAdapter somewhere. """
You're right that it needs to happen before the call happens, but the caller isn't required to do this. The provideAdapter call is typically done outside of any direct caller. In Zope, it's typically not even done by writing Python; it's done instead by writing ZCML. You may hate this, but it does mean that you don't need to modify the caller.
In the Java world there is a saying: You can always count on an architect to provide another level of indirection (to not really solve not really a problem).
The example Chris provides is simple, in more complex systems I find this pattern dramitcally decreases the amount of code requiring change. To say, "In the Java world there is a saying: You can always count on an architect to provide another level of indirection (to not really solve not really a problem)." is an irrelevant association. The problem that this added indirection solves is that we do not have to change code. Callers do not need modifying, all that has to change is the registration (done in configuration in the case of Zope).
Fredrik didn't suggest we pass in a Churner to the churn method. He suggested we use a superclass with a template method (a different GoF design pattern). A subclass would provide a method that returns a particular kind of churner, which would be called by the superclass "churn" method. And that's fine; it solves the example problem I proposed nicely. It does fail to solve the case of wanting to adapt something to something else when neither one of those things are "self", though. Nothing in the example code requires this, but it does happen.
""" Otherwise, the caller would still need to call the provideAdapter somewhere. """
You're right that it needs to happen before the call happens, but the caller isn't required to do this. The provideAdapter call is typically done outside of any direct caller. In Zope, it's typically not even done by writing Python; it's done instead by writing ZCML. You may hate this, but it does mean that you don't need to modify the caller.