On Mar 1, 11:54 pm, Stuart McCulloch <[email protected]> wrote:
> 2009/3/1 bank kus <[email protected]>
>
>
>
> > Would it be totally unjustified to say this is working around the
> > problem not solving it. Consider I m using Components A and B to build
> > up Component C. Except that component A and B are layered compnents
> > build using 50 other components.
>
> note that your module structure does not have to mimic your application
> structure,
> you could have a nested application model that is configured with a flat
> sequence
> of modules (personally I'd avoid nesting modules unless absolutely
> necessary)
>
I would like to respectfully disagree though I must say the
overwhelming advise I have seen around building components has been
what you just said both here and in Spring.
I would want to write components not applications. I do not know what
application will use my component and along with what other
components.
I want to build a town that has some houses a recreation park and a
shopping complex. As a townbuilder I would like to choose from some
preconfigured houses;
<a> ContemporaryDesign
<b> ClassicDesign
<c> UrbanDesign
While its possible for me to break up ContemporaryDesign and see what
flooring/furnitures/fireplace/door panels/kitchen designs its made up
of I choose not to. Nothing about the internal composition of
ClassicDesign should render it unusable in my town along with
UrbanDesign houses or with OpenAirShoppingComplexDesign.
banks
> but if I did want to use a nested module setup where component C built on
> A+B
> then perhaps something like this might help (I have not tried this in
> practice!!)
>
> C -- PrivateC
> / \
> / \
> / \
> A B
> | |
> | |
> PrivateA PrivateB
>
> ie. I'd use a private module in C to bind types that might also be bound
> later on
> inside A or B, and only expose what I wanted to make public from component C
>
> then when C pulls together A, B, and PrivateC there shouldn't be any
> conflict
>
> Now what this would mean is in Component C if I need a Logger I can no
>
>
>
> > longer setup a binding inside a module since chances are its used by
> > one of the lower components with a different binding so I only ever
> > have to use Providers. Perhaps I am missing something colossal in
> > which feel free to point that out and I ll go back and reread Guice
> > docs /watch the videos (which are excellent btw) and play with the
> > examples/tests in the source package :)
>
> > banks
>
> > On Feb 28, 2:24 pm, Bob Lee <[email protected]> wrote:
> > > On Sat, Feb 28, 2009 at 2:12 PM, bank kus <[email protected]>
> > wrote:
> > > > Though we still need to solve this problem where a top level component
> > > > requires an extremely low level component while some of the components
> > > > it uses also use this low level component with different bindings.
>
> > > You can also use provider methods (for example to construct the fireplace
> > > manually and make sure you throw in the right piece of wood).
>
> > > Bob
>
> --
> Cheers, Stuart
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
