On 10/28/05, Luke Palmer <[EMAIL PROTECTED]> wrote: > Here's how I see roles. This is just an attempt to formalize our > concepts so that the answer becomes an obvious truth rather than a > decision. > > A role is an interface with some default implementations.
-snip- > Now we ignore the inner workings of FooBar and Baz. This is a good > idea, as it lets us refactor freely, as long as it looks the same from > the outside. I would say that this isn't just a good idea; it's at the core of what distinguishes composition from inheritance. With classes and inheritance, you keep all of the baggage that accumulates at each step, on the off-chance that some as-yet unknown descendant might need it. With composition the only baggage that a role keeps is the baggage that is directly relevant to itself. Whatever gets tossed aside can be composed in separately later on if it's needed. > Recall that we had: > > Baz: bar() default > FooBar: bar() required > > So clearly Baz fulfills FooBar's requirements, and MyClass is a > fully-defined role. > > Okay, how did that happen? What was the formality that we actually used? > > It was the fact that at each stage of the game, we summarized the > defaults and requirements for each role, ignoring the internal makeup > (i.e., what roles were composed into it, etc.). > > And it sounds correct to me. Me, too. -- Jonathan "Dataweaver" Lang
