|
|
Re: Scala's Stackable Trait Pattern
|
Posted: Oct 7, 2009 8:07 AM
|
|
> Hi John,
>
> > > class composition instead of object composition.
> > Stackable
> > > traits decorate the core traits at compile time,
> similar
> > to
> > > the way decorator objects modify core objects at run
> > time
> > > in the decorator pattern.
> >
> > This is somewhat incorrect. Role analysis is actually
> > meant to unify object-based and class-based methods for
> > decribing patterns of interactions between objects.
> >
> Can you elaborate? I'm not sure what your saying is
> somewhat incorrect.
>
> My goal was to preempt folks from concluding that this is
> just decorator, because the GoF book makes it clear that
> the intent of decorator is (quoting the book) to:
>
> Attach additional responsibilities to an object
> dynamically. Decorators provide a flexible alternative to
> subclassing for extending functionality.
>
> Whereas this is an example of "subclassing to extend
> functionality" really, and it isn't dynamic. What's new is
> Scala's notion of delayed binding of the meaning of super,
> abstract override, and linearization, which didn't exist
> when the GoF book was written. The decorator pattern looks
> in Scala pretty much the same as it does in Java. So even
> though this has a similar structure to decorator, is a
> similar concept, it really is different from decorator,
> because it is a static, compile-time thing.
Hi Bill,
I am referring to the symmetry between the GoF Decorator pattern GoF State pattern (which Trygve essentially wrote an entire book about, as well as an object-oriented software method for). The GoF State pattern in the book is described as a behavioral pattern, but its more structural in nature: the focus, as in Trygve's OOram (his software method), is about defining the context in which a behavior is applicable. Within that context, you are modeling the structure of object interactions. GoF sees it as a behavioral pattern mainly because their implementation is synchronous with its environment; each role knows where to migrate the token to next. In an asynchronous environment, the pattern is purely structural in nature because the objects communicate by message-passing and state transitions are triggered by signals.
Traits allow you to more easily specify contracts for what sort of compositions an object allows.
As I said, role analysis is actually meant to unify object-based and class-based methods for describing patterns of interactions between objects (this is almost a word for word quote from Trygve). Most of the examples in Trygve's book Working with Objects is dedicated to this idea. The only unfortunate thing is Trygve doesn't really discuss "dependency injection" in conjunction with that big picture idea, so the reader likely does not see the "big idea".
> Whereas this is an example of "subclassing to extend
> functionality" really,
As you subclass to extend functionality, you are changing the problem domain. This is mainly due to the fact that in your example you are not using scala's features to encapsulate some problem domain but rather demonstrate some wiring pattern. The wiring pattern is a code reuse facility with excellent type safety, but it is a clumsy way to package a problem domain.
> and it isn't dynamic.
To wit, I would argue asynchronous message-passing is dynamic, whereas hardwiring sequences of collaborations is static.
The hard problem to solve in OO is not structural. OO applications are filled with structural features. The hard part is to specify at the language level your object interactions (use cases).
|
|
Previous Topic
