I'm new with Java Guice, and I have trouble with designing my application.
I'll try to explain my design and the desired result as simple as I can.
I have an interface called Ialgorithm, and 3 implementations of that interface, lets say IalgorithmA,IalgorithmB,IalgirthmC.
I have a class called myClass with the following constructor:
public myClass(Ialgorithm alg) {...}
Now I want to be able to inject an instance of one of the implementations of the Ialgorithm interface, using annotations:
I want at the end to be able to write in my main:
// ... intialize an Injector with a Moudle that extents AbstractModule
myClass a = injecotr.getInstance(key.get(myClass.class,Aannotation.class));
myClass b = injecotr.getInstance(key.get(myClass.class,Bannotation.class));
myClass c = injecotr.getInstance(key.get(myClass.class,Cannotation.class));
I read a few tutorials in the web, but I couldn't find exact way to achieve this.
In addition, and after the above issue will be solved, I extend my question:
Actually, The third implementation, IalgirthmC, is different from the two other implementations which contain a default constructor: its constructor is:
public IalgorithmC(Ialgorithm,int n) {...}
Now it becomes more complicated... because I want the Guice to inject the Ialgorithm parameter, but the int parameter shouldn't injected by the Guice (#Assisted), and this whole instance of IalgorithmC should be injected into myClass when using the Cannotaion.
Of course that I should provide a value for the int parameter and an annotation to the internal Ialgorithm in IalgorithmC.
Thank you all for any help.
This question talk about one solution for multiple implementations in guice.
Related
So I'm implementing a Dependency Injection framework into my Java project (Google Guice) and everything is pretty good, I like it but there's a small problem;
I want to make a static instance of my main project's class (where it instantiates the dependencies, etc). But I don't know any method to instantiate it using Guice, I can't instantiate it manually because I'm using DI in the constructor of it (I have objects in the constructor) which means that I am not able to access the class' non-static variables needed to instantiate the class.
I tried using a Provider but I couldn't really understand where to bind it, because I don't want to have an interface for the main class (will if needed).
If you are wanting to mix a static instance of a class with dependency injection, you have somewhat missed the point of dependency injection: you can simply inject the instance of the class.
If you want there to be a single instance of a class for your injector, bind it in #Singleton scope: either:
bind(YourClass.class).in(Singleton.class);
in your module's configure() method, or
#Provides #Singleton YourClass provideYourClassInstance() {
// ...
}
in your module, or
#Singleton class YourClass {
// ...
}
in the actual class declaration.
Then just inject this instance like any other:
class SomeOtherClass {
#Inject SomeOtherClass(YourClass instance) {
// ... Do something with instance, like assign it to a field.
}
}
The point is that SomeOtherClass shouldn't need know anything about the lifetime of instance: it simply doesn't matter whether this is a singleton instance, or every class using it has its own instance.
You can get three different answers here depending on the question.
To directly answer the question in the title (DI with arguments in the constructor), you can mix DI with constuctor arguments by instead injecting a Factory. Though you're welcome to write one manually, Guice can do this for you as assisted injection (see FactoryModuleBuilder), or you can use the equivalent code-generated solution AutoFactory popular through Dagger.
If you're trying to initialize a static class's fields in a Guice application, Guice can do that for you as soon as the Injector is created. Simply call requestStaticInjection in a Module you feed to Guice. This, as Andy Turner pointed out, will cause you to miss out on some of the benefits of Guice: Because you're injecting the instance statically, there's very little opportunity for you to provide replacement implementations in tests or in other class reuse. Guice describes this more in the static injections section of its wiki:
When migrating an application from static factories to Guice, it is possible to change incrementally. Static injection is a helpful crutch here. It makes it possible for objects to partially participate in dependency injection, by gaining access to injected types without being injected themselves. [...]
Static members will not be injected at instance-injection time. This API is not recommended for general use because it suffers many of the same problems as static factories: it's clumsy to test, it makes dependencies opaque, and it relies on global state.
The best overall solution is in Andy's answer: Adapt your application to use DI, which will let it inject the objects that you would otherwise make static.
I want to achieve DYNAMIC dependency injection. Does GUICE support this? If not could you recommend any other DI framework?
The implementation that should be used for injection via #Inject must be determined during runtime e.g. via interaction with the user.
Similar to these questiones:
http://www.panz.in/2008/12/dynamic-dependency-injection.html
http://www.panz.in/2008/12/dynamic-dependency-injection.html
Thank you
The implementation needs to vary based on input, at some point you're going to have to resolve the input into some kind of class.
If you want that mapping to live in Guice, then you're basically getting an implementation based on a parameter, which maps to the SO question I just answered here. You can write a small injectable class that takes the input and returns a fully-injected implementation.
If you already have that mapping and have (for instance) a class literal in a variable, then you can just inject an Injector directly and ask it for the implementation.
class YourClass {
#Inject Injector injector;
SomeInterface yourMethod(String input) {
Class<? extends SomeInterface> clazz = getClassLiteralFromInput(input);
return injector.getInstance(clazz);
}
Class<? extends SomeInterface> getClassLiteralFromInput(String input) {
// Implement this as needed.
return SomeInstance.class;
}
}
Note that while you can always inject an Injector, you should only do so when you really don't know what kind of implementation you need (like here). In general you should inject the SomeInstance itself, or a Provider<SomeInstance> if you want to delay the creation.
We had similar requirement once, so what we did was use a factory pattern and add all the implementations in factory class implementation using spring.
That ways, when on run time we would know which implementation to use, we would make a call to my factory to provide implementation class.
Also, anytime you have more implementations you could update spring configuration for factory class.
This may not be close to design you have in mind, but this solved the purpose for us.
Cheers !!
I have two classes A and B which both implment the interface Z. Now, class A should for some functions of Interface Z (Z.f1, Z.f2, Z.f3, ...) only work as dispatcher to an object of class B.
public class A implements Z{
private B b; //instantiated in constructor of A
#Override
public String f1(int p)
{
return b.f1(p);
}
...
Is there a generic way to do this in Java?
If you mean that method f1() is declared in interface Z the pattern you want to implement is called wrapper or decorator.
In java you can create generic implementation using dynamic proxy introduced to java 1.4.
I don't think so. But sometimes your IDE can assist in creating all the simple methods to delegate the calls. And sometimes you can find third part classes to do this. For example, Guava (http://code.google.com/p/guava-libraries/) has a ton of ForwardingXXX classes, which, by default, delegate everything to something else. For example, ForwardingMap delegates all calls to another Map. You need to override the methods that you do NOT want to delegate.
I have been challenged by a design issue which I will try to describe below.
Suppose that a class, call it A, has a constructor with a bunch of parameters. Since it is tiring and dirty to write all those parameters in each instantiation, I have written another class, call it StyleSheetA, which encapsulates all those parameters and is the only parameter to the constructor of A. In this way, I can prepare some default StyleSheetA templates to be used later, and if it is needed, I can modify them.
And at this point, I need to extend A. Suppose B extends A. B will have its own stylesheet, namely StyleSheetB. I think it will be appropriate that StyleSheetB extends StyleSheetA, so with one stylesheet parameter, constructor of B can also construct its super class A. But I am afraid of the possibility that this design may have flaws. For example what if I decide to add a getter/setter for the stylesheet? Is there a novel way to handle all these situations? Am I in the wrong way? For those who are confused, I attach some code here:
class A
{
StyleSheetA ss;
A(StyleSheetA ss)
{
this.ss = ss;
// Do some stuff with ingredients of styleSheet
}
}
class StyleSheetA
{
int n1;
int n2;
// :
// :
int n100;
}
class B extends A
{
B(StyleSheetB ss)
{
super(ss);
// Do some stuff with ingredients of styleSheet
}
}
class StyleSheetB extends StyleSheetA
{
int n101;
int n102;
// :
// :
int n200;
}
Thank you for any help or suggestions, also any of your critics will be appreciated.
Edit: I am developing in java me so there is no generics support.
It seems to me that you are only moving the problem of having too many parameters from class A to class StyleSheetA.
To illustrate my point, think of this question: How would you instantiate StyleSheetA? Probably using a constructor that accepts all these parameters, anyway. The only benefit this design may give you is if you have a same set of parameter values encapsulated by an object of StyleSheetA which you will reuse among multiple instances of A. If so, bear in mind that although you'd have different instances of A they would share the same parameters, so it isn't a good choice.
What I could recommend you is to try to refactor your class A itself. Try to break it up into smaller classes. If nesseccary, try to create subclasses to avoid conditional branches, etc.
Now, I don't know how your class A looks like, but maybe if you do so you'll have several classes, each with its own set of parameters. And if any of the parameters is a discriminator (meaning that it determines the class "type") you will be able to get rid of it, just by using subclasses, and relying on built in type system to do it instead.
Have you considered using an IoC container, like StructureMap, to manage your constructor dependencies? That might make a lot of this stuff easier.
A thoughts on the getter and setter issue:
The constructor in 'B' implies that the additional parameters (n101+) are necessary for the operation of the class. If you were just extending the class with a full parameter list, you would have getters and setters for n101...n200 in B and n1...n100 in A. This suggests perhaps not having StylesheetB extend StylesheetA, but rather have the constructor to class B be B(StyleSheetA,StyleSheetB), this way you can have a setter in class A for it's parameters, have that inherited and also put one in B for StylesheetB.
I want to be able to call Interfaces in my class, but have spring instantiate them with the right implementation class behind the scenes.
I.e. Normally you can do:
IClass clz = new Class();
I want to have the line IClass clz; preferable in the middle of a method (or as one of the attributes if it can't be done), where clz is instantiated to the class I want by Spring.
The reason I'd like to do it this way is because I want to be able to be able to change which implementation I want to use simply by editing the context files.
Even better, would be knowing how to do the above with class contructors that expect parameters. i.e. new Class(ar1, arg2);
I hope this makes sense. Any help would be much appreciated.
You can make your class implement BeanFactoryAware and then Spring will inject the bean factory in your class. If you then want to get an instance of a class implementing your interface you say something like:
beanFactory.getBean(IClass.class);
If there are multiple beans that implement the same interface you will have to resolve by name. To create a new object each time you ask this, set the bean scope of the bean you're asking for to "prototype".
You can include code such as:
ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");
IClass clz = (IClass) context.getBean("beanName");
Not saying this is better per se than Gerco's answer btw, just it's an option, depending what you want to do.
You can also implement the ApplicationContextAware interface: I've found that using ApplicationContext gives me beans with filled-in properties, e.g. if you have an app.properties file which contains key/value property pairs which you expect to be resolved within the Spring config, beans retrieved via BeanFactory calls may not resolve those.
See this previous SO topic for more info.