I use singletone classes, are injected by dagger. But if synchronized methods start running, but they terminates. But if I remove synchronization from methods, they run well.
If I inject sungletone classes by dagger, I shouldn't use synchronized methods?
Dagger and Dagger 2 singletons and scoped providers use internal double-checked synchronization. If you're writing a singleton #Provides method, it will be called exactly once in a synchronized environment, so you probably won't need to worry about it.
Unless your #Provides method does anything thread-unsafe and is expected to be called multiple times, don't worry about marking anything synchronized.
Related
I read so many bad things about singleton pattern (What is so bad about singletons?), however, #Singleton is used everywhere in this Micronaut doc to illustrate inversion of control https://docs.micronaut.io/1.3.0.M2/guide/index.html#ioc
When is it appropriate to use #Singleton? For example, if I have a UserInfoService that has getUserInfo, createUserInfo, updateUserInfo method, is it a good idea to use #Singleton?
Another separate question is when do I use #Prototype, because if I don't use any annotation for a function/class, isn't it by default a prototype (as in I initiate a new instance of it in another class/function)?
When is it appropriate to use #Singleton? For example, if I have a
UserInfoService that has getUserInfo, createUserInfo, updateUserInfo
method, is it a good idea to use #Singleton?
UserInfoService should almost certainly be a stateless singleton.
Another separate question is when do I use #Prototype, because if I
don't use any annotation for a function/class, isn't it by default a
prototype (as in I initiate a new instance of it in another
class/function)?
If you initiate a new instance, then the annotation doesn't matter. The annotation only affects instances that the Micronaut container creates for you. For #Singleton the container creates a single instance and injects the same instance at all injection points that require it. For #Prototype the container creates a new instance for each injection point.
All of this is about application design more than it is about Micronaut. Micronaut provides a simple mechanism for you to declaratively express (by way of #Singleton or #Prototype) whether or not you want the same instance to be shared or not but the issue is really about application design. In general you should prefer stateless singletons. If for some reason you have a bean that must be stateful and you have good reasons to not want to share instances from different contexts, then #Prototype might be appropriate.
I hope that helps.
Let's be 100% clear that the GoF Singleton design pattern and the #Singleton annotation are two different things.
Consider that the Singleton design pattern requires you to change your code. You must write the code in such a way as to prevent multiple instantiations.
On the other hand, you can add the #Singleton annotation to any class you like, without modifying its code to prevent instantiation; and as #Jeff-Scott-Brown points out, you can instantiate this Micronaut "Singleton" repeatedly by simply calling its constructor.
The #Singleton annotation does not exhibit those negative consequences you've read about in the Singleton design pattern, because it doesn't implement the Singleton design pattern. The term is overloaded to mean two different things here.
On a related note the #Prototype annotation doesn't follow the GoF Prototype design pattern either. Spring prototype following prototype design pattern
As Jeff Scott Brown covers most parts of your question, your have to be careful to the nuance between Singleton scope in Spring and singleton pattern.
Some of the main differences between these 2 are
Singleton pattern ensures one instance of a particular class of per
class loader.
Spring Singleton is “per container per bean”.
Hope that helps.
Apparently, singletons are bad, and a factory method is recommended. I'm wondering if a singleton toolbox is any better than a singleton.
In my opinion, It's really weak to think that singletons are bad,factory methods are good.
Each of them has preferences. As consequence, I'm sure that there is misunderstanding here.
I know that wikipedia is not the best source. But check out the definition of them. The range of situations are not the same for these patterns.
In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.
In class-based programming, the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created. This is done by creating objects via calling a factory method—either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.
I seem to need this a lot.
Let's say I have a class with constructor taking several arguments. Some of these can be resolved by registering components. But the rest are instances created during runtime (e.g. fetching an entity from database).
Can Autofac deal with these situations in a nice way? Or is my design sub-optimal?
To clarify, I have classes that have constructors like this:
public MyClass(IService1 service1, IService2 service2, Data1 data1, Data2 data2)
{
//...
}
And I would like to do something like this:
container.Resolve<MyClass>(data1, data2);
You can handle this elegantly by registering a factory method in the Autofac container. You resolve the factory method, and then use it to create instances with your runtime dependencies. You can do this yourself by registering and resolving delegates or custom factory types. However, Autofac has explicit support for delegate factories.
There is not enough information to comment on your design. I'll leave that to you :)
I would say your design is sub optimal.
You seem to be mixing to things. Dependency injection (using a container) should mainly be used for injecting service components into other components. Don't inject thing like entities, because it is not up to the container to manage their lifetime. Rather, inject a service that can manage entities for you, such as a repository. Although topic of discussion, I would neither inject a unit of work, but rather a factory for creating unit of works. This way your application manages the lifetime of the unit of work explicitly.
If method A() calls static method B(), this is bad because the two are tightly coupled, correct?
But if, instead of calling B(), A() called a non-static method C() of some concrete class, this would be equally bad for testing, correct? Because now A() is coupled to the concrete class that owns C().
The only good scenario happens when interfaces (i.e., dependency injection) are used, and A() calls the interface's method.
Do I have it right? Are there any other reasons static methods are bad for testing?
The first scenario is "bad" because it makes is hard to exchange what B()is being called.
The second scenario is possibly not quite as "bad" because, depending on how you get your instance of the class that owns C(), you might be able to exchange that object for another (say a subclass).
The third scenario is typically "best" since it allows you to easier change the implementation of A(), but this is only true if there is no hard-coded construction of a concrete class providing A() (i.e. only tru if dependency injection is actually used).
It depends on the language. For instance, in a language like Java calling an instance method on a concrete class is not bad for testing at all, because a proxy instance for that concrete class can be generated, allowing the calls to be intercepted (and typically, mocked out) effectively. In fact, many frameworks use this proxy facility to inject their own code before/after user code in order to provide features like dependency injection and AOP support.
I have a singleton class which needs to be intialized by castle? I'm a little newbie in castle. I have looked for singleton in castle and I saw setting the lifestyle attribute of component to "Singleton" seems enough. But in that case it seems I don't need to implement the class in "Singleton Pattern". Just plain class definition for my class seems ok.
Is castle provide my class as singleton to me even I define it as a normal class? Or I am missing something?
No, you are absolutely right - the container will instantiate your class the first time it is needed, and from then on the instance will live inside your container.
Stay away from the singleton pattern - it is evil! :)
(no, seriously - there are very few cases where implementing a singleton is acually necessary... and if you are using an IoC container, you will never have to implement singletons by using static instances, which can seriously hurt your design by coupling your classes to those static instances)