Anders Norås wrote:
> On 23. feb.. 2009, at 15.05, Rickard Öberg wrote:
>> Changing these kinds of things at runtime is just bad practice and
>> will
>> lead to unreadable software, so we don't support this.
>
> That's understandable, but you know how I really like to push things
> beyond the limit to prove a point ;-)
And the point is...? All I can see so far is that you want something
that can do what you say. But not all runnable programs are useful...
> Anyways, thanks to both Nicklas and Rickard for some good pointers. I
> rewrote the example to have explicit WesternPersonComposite and
> JapanesePersonComposite interfaces which reference different mixins
> for the two behaviors. These interfaces extend a common
> PersonComposite interface which has the shared behaviors between the
> two. This works, and its not too far away from the Ruby example to
> show the similarities in how one can do composite reuse.
> The client code a few lines longer than my Ruby-based example, but its
> not too much to live with:
>
> public void assemble(ModuleAssembly module) throws
> AssemblyException {
> module.addComposites(WesternPersonComposite.class);
> module.addComposites(JapanesePersonComposite.class);
> }
> };
> CompositeBuilderFactory builderFactory =
> assembly.compositeBuilderFactory();
> CompositeBuilder<WesternPersonComposite> builder =
> builderFactory.newCompositeBuilder(WesternPersonComposite.class);
> builder.stateOfComposite().firstName().set("Nancy");
> builder.stateOfComposite().lastName().set("Carthwright");
> Person nancy_carthwright = builder.newInstance();
> Assert.assertThat(nancy_carthwright.fullName(),
> equalTo("Nancy Carthwright"));
> CompositeBuilder<JapanesePersonComposite> japaneseBuilder =
> builderFactory.newCompositeBuilder(JapanesePersonComposite.class);
>
> japaneseBuilder.stateOfComposite().firstName().set("Hayashibara");
> japaneseBuilder.stateOfComposite().lastName().set("Megumi");
> Person hayashibara_megumi = japaneseBuilder.newInstance();
> Assert.assertThat(hayashibara_megumi.fullName(),
> equalTo("Megumi Hayashibara"));
You can do it that way, but it doesn't show off the contextual potential
of Qi4j. If you instead just refer to "PersonComposite", and let the
context decide which one is chosen, then you're on to something, because
then the client doesn't have to know which one is actually chosen! The
client code becomes reusable and embodies an abstract idea rather than
having to know the details. Encapsulation, abstraction, separation of
concerns, and all that jazz.
And this is of course the complete opposite of the Ruby code, in which
the client code not only has to know the abstract idea of what it wants,
but also has to compose it on its own. Horrible, but it will certainly run!
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
