On Sat, Dec 27, 2008 at 12:02 AM, Larry Garfield <[email protected]>wrote:
> On Friday 26 December 2008 11:06:07 pm Nathan Nobbe wrote:
>
> > to summarize, using your example above, i would most liely add doThings()
> > to Baz, or create another decoration interface for doThings() if you plan
> > on using the Bar implementation of doThings() in many places,
> >
> > interface G {
> > function doThings();
> > }
> >
> > class Bar extends Decorator implements G {
> > function doThings() {
> > // concreate implementation
> > }
> > }
> >
> > class Baz implements F, G {
> > // recycle Bar::doThings()
> > public function doThings() {
> > return $this->foo->doThings();
> > }
> > public function doOtherThings() {}
> > }
> >
> > i appologize if this response is long winded, but im a big fan of the
> > decorator, and ive actually got some pretty slick code in production in
> the
> > photobucket code that uses the decorator pattern :D it took about 2
> months
> > to code, and i leraned a lot about some of the practical aspects of
> > decroration, specifically within the realm of php. i know i repeated a
> few
> > things there, but i felt it neccessary to better explain myself.
> >
> > -nathan
>
> Thanks, Nathan. Unfortunately, what you describe is impossible. It
> requires
> me to know all the possible decorators ahead of time and implement the
> interface for each in each decorator, at which point I've gotten no benefit
> at
> all over just putting everything in the original base class in the first
> place.
> That defeats the purpose of decorators if I can't come up with a new one a
> month from now and not have to modify any of the existing code.
i see it more on a need-to-expose basis. for example, why not, when
presented w/ the current problem, just expose, Baz::doThings() now, b/c you
know you need it in Baz instances ? later if you find theres another method
thats in Bar that isnt yet exposed, you just go in and add a similar wrapper
for it in Baz at that time. this is a typical flow in a layered
architecture in my experience; often times controllers are revised to expose
a new entry point for something on the backend that previously was
unavailble from the front end, just as an example.
i only pull interfaces into the equation when i what to bring a group of
things together, it certainly isnt necessary to define a second interface,
but i was just trying to highlight doThings() as your example essentailly
had 2 layers of decorators, G(F(Foo)), as i saw it. from a design
perspective, yes, id probly not define G unless / until i saw a need to join
a group of classes explicitly.
-nathan
