Re: Best way to implement a Provider of a class and its sub-classes

[Olivier Grégoire]

Hi Albert,

Why don't you group your classes by domain (all services and models related to one domain go in one package) rather than by functionality (group all models together, group all services together)? This way you can use package-private constructors. Plus it will be easier and more logical for your readers to find the classes you are referring in your services and you can reduce the size of your imports.

Also, if ChildClass1 and ChildClass2 are pojos, which seems likely given your structure, you can simply use "new" instead of going through a factory. Using Guice for Pojos is like using a bazooka to kill fly when good old fashioned tools still do the job properly.

Regards,

Olivier

2013/5/8 Albert Serrallé <albert...@gmail.com>

Hi all,

I'm wondering what's the best design to build a provider.

My library consists in a service package with a service class. In other package I store the model class, which I want it to have protected constructors. The model is a super-class (abstract) with some sub-classes (extending the super-class).

/model/

    SuperClass

    ChildClass1

    ChildClass2

    ...

/service/

    Service

I want to get instances of the sub-classes from (and only from) the service class. Guice Providers seem to be lacking the capacity of doing something like:

public class ModelProvider extends Provider<SuperClass>{

  public SuperClass get(Class type) {

    return "new instance of type";

  }

}

I can't invoke get with parameters. Also, if the constructors of the model classes are private, the provider must be in the same package, which I think is a bad design for my library.

Any advice?

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Olivier Grégoire

[Christian Gruber]

I think you're trying to use Guice AS IF it were an ORM tool. It is not
really in Guice's wheelhouse for Guice to act as a manager of this sort
of class. It can be done, but it starts to torture your object graph a
bit and (mis?)use the internals of Guice to coerce it into being a
different sort of framework.

At this point, I'm wondering why you're not just using toplink or
hibernate or something that is actually really built around managing
domain objects, and using Guice to manifest your collaborators?

Christian.

On 15 May 2013, at 7:38, Albert Serrallé wrote:

> Hi Olivier,
>
> They are not pojo's, that's the reason I want Guice to provide the
> instances.
>
> The model classes are wrappers, with a reference to a DAO (for now
> I've
> implemented it as a static reference). And you can instantiate the
> wrappers
> with two different constructors (one creates the wrapped object, and
> the
> other one initializes a wrap around an existing object). Finally, I
> want to
> use Guice interceptors on wrapper methods... I'm afraid that it won't
> be
> possible.

>
> El miércoles, 8 de mayo de 2013 16:02:49 UTC+2, Olivier escribió:
>>
>> Hi Albert,
>>
>>
>> Why don't you group your classes by domain (all services and models
>> related to one domain go in one package) rather than by functionality
>> (group all models together, group all services together)? This way
>> you can
>> use package-private constructors. Plus it will be easier and more
>> logical
>> for your readers to find the classes you are referring in your
>> services and
>> you can reduce the size of your imports.
>>
>> Also, if ChildClass1 and ChildClass2 are pojos, which seems likely
>> given
>> your structure, you can simply use "new" instead of going through a
>> factory. Using Guice for Pojos is like using a bazooka to kill fly
>> when
>> good old fashioned tools still do the job properly.
>>
>>
>> Regards,
>> Olivier
>>
>>

>> 2013/5/8 Albert Serrallé <albert...@gmail.com <javascript:>>

>>
>>> Hi all,
>>>
>>> I'm wondering what's the best design to build a provider.
>>>
>>> My library consists in a service package with a service class. In
>>> other
>>> package I store the model class, which I want it to have protected
>>> constructors. The model is a super-class (abstract) with some
>>> sub-classes
>>> (extending the super-class).
>>>

>>> */model/*
>>> * SuperClass*
>>> * ChildClass1*
>>> * ChildClass2*
>>> * ...*
>>> */service/*
>>> * Service*

>>>
>>> I want to get instances of the sub-classes from (and only from) the
>>> service class. Guice Providers seem to be lacking the capacity of
>>> doing
>>> something like:
>>>

>>> *public class ModelProvider extends Provider<SuperClass>{*
>>> * public SuperClass get(Class type) {
>>> *
>>> * return "new instance of type";*
>>> * }*
>>> *}*

>>>
>>> I can't invoke get with parameters. Also, if the constructors of the
>>> model classes are private, the provider must be in the same package,
>>> which
>>> I think is a bad design for my library.
>>>
>>> Any advice?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an

>>> email to google-guice...@googlegroups.com <javascript:>.

>>> To post to this group, send email to

>>> google...@googlegroups.com<javascript:>
>>> .