Re: Value Object: static factory or assisted injection ?

[Stephan Classen]

I personaly try to avoid DI for value objects. I might have factories if this is required but those will be hand written since they are usually non trivial. But most of the time I just instantiate them using new.
Since they should not contain any business logic and expose their entire state by getters I dont even have problems in unit tests since I can validate the state of the value object.

If you feel that assistad injection is a tool that helps you cut down the boiler plate code for your value objects then go ahead and use it. You most likely will find many opinions on this topic.
An advice which I found in an older discussion on this group was to have your factory as a pubic static inner class/interface of the object it creates. This keeps the factory and the object close together.

Am 22.08.2014 19:43 schrieb Maatary Okouya <maatar...@gmail.com>:

Hi, 

First let assume that everybody agree that there is nothing wrong with injecting some value object into injectable object such as service. Indeed, a service can get another service injected, but could along the way get some configuration information as well. Configuration information that would be represented as Value object. 

Now let's talk about using DI framework, on value object directly. I intentionally do not say, let's apply dependency injection on value object, because i see the critics coming about what is a dependency and etc...

Here is what can be red everywhere:

 Using DI for Value object is wrong or useless. They are newable. They do not have real dependency.

• In general i would first disagree with the idea of newable. I think it is a good practice to use Factories anyway. it leaves you some control over how exactly the object is created and what strategy, you may use behind and etc... The factory itself could be configured and etc...One could even think about changing the implementation instantiated for the given interface of a value object, based on the operating system constraint or whatever condition you may think of.

Let us now assume that we all agree to use factories for value object creation. Building on that, I would like to develop the following point:  Can a DI be used as a simple factory tool, when it comes to value objects? 

Why I'm asking this: 

• Because i want to use factories as exposed above.
• I don't want to scattered around my value object creation . (Is that legitimate ?)

This means that i will definitely use assisted-injection all the time to create my value object. Another way would be to use static factories in my code, etc...

In essence using a DI as factory container for you value object, means that you will be likely to pass factories as parameter of your services, to allow them to create those value objects. 

Which one do you use? why ? Why would you be against one or the other ? 

Do you prefer to use a static (Singleton / anti-pattern ?) in the middle of your service code, or you would rather inject your factory, weather it via a DI or a factories that non static ?

Best,

M

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/38248d37-9da2-46bc-afb3-b1f5970486f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Maatary Okouya]

Thank you for your inputs. Actually, i agree with you that at most a factory is enough. Using assisted injection for value object creation is just too over-kill; Especially if this leads to wiring factories in services that needs to creates them. This can be taken further. Does the "service of creation of some value objects" is a dependency to your service ? So whether you have your own factory or one produce by google guice, is it worth to inject it as a dependency ? Probably the last solution that you propose is much better (static inner class). I use scala, and something similar is provided automatically with case class. I think this i will go for that late solution.