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. *
On Friday, August 22, 2014 9:14:53 PM UTC+2, scl wrote: > > 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 <[email protected] > <javascript:>>: > > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected] > <javascript:>. > 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 > > <https://groups.google.com/d/msgid/google-guice/38248d37-9da2-46bc-afb3-b1f5970486f7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/f2f53d55-55a2-4901-8fdc-24f5ce497675%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
