Tag Info

New answers tagged

1

The context of your application decides everything. To illustrate why this is true, let us first start with the purpose for inversion of control or IOC. The purposes behind IOC are extensibility and horizontal scaling. In extensibility, the application needs to decide what implementation to use under a particular set of circumstances. For example, if ...


1

You can do like this: public class XXXUtils { @Autowired private DataAccessService dsService; private static XXXUtils utils; @PostConstruct public void init() { utils = this; utils.dsService = this.dsService; } public DataAccessService getDsService() { return dsService; } public void ...


2

The main problem with your second approach of injecting factories is that it removes one of the benefits IoC/dependency injection provides - You no longer know which repositories the class depends upon without digging through the code. While this is not as 'bad' as creating the repositories itself, the class still needs to know how to request them from a ...


3

Good Question! When the service becomes complicated, the number of dependencies will grow more and more In that case your dependencies are maybe not standalone dependencies but can be grouped into simple dependency-holding classes that can be used to pass into the constructor. A good sign would be if more than one of your classes use both IRepositoryA ...


0

Basically it would not be a good idea to put container logic inside a library. When you want to use the DatabaseUtilities library in another project that uses another dependency injection framework, you still have the dependency with Unity. So in this case it would be better to move the bootstrap class to your main project. Putting the bootstrap logic inside ...


1

Your modified approach to singleton is still a singleton, and has most of the drawbacks of a singleton: It still introduces high coupling across the application - that is, if one day you want to refactor away from singleton, you will have a hard time doing it; It still gives a way for any component to collaborate with the singleton - meaning that ...


3

Static data (including singleton instances) is problematic for a number of reasons. It's not thread-friendly. You have added a method to set the single instance to a mock instance. Presumably that is done to support unit testing. This will fail if tests are run in parallel and require different mocks for your Singleton. Worse, the tests will fail when ...


2

The reason I give dependencies to constructors is: Most of the time the dependencies are required, so why not give them to the constructor Giving them to the object in an other way makes using them a bit more complex, since you have to make sure you have the dependency Of course this doesn't really count when you are using a framework that controls the ...


0

I suppose you are trying to make the game engine Process-driven. I.e. Process will decide what should happen it the game and change game's state. I like the idea, but I was never able to apply it to my game (I've finished only one). The core of the problem was that my game was not truly process-driven. The inputs came from the frontend (Screen or ...



Top 50 recent answers are included