abstract-factory

I have a SocketManager class that contains a Socket and other fields. All fields except the Socket can be injected during the composition of the object graph with a DI framework. My idea was to simply build the entire object graph upfront by leaving Socket empty and set it during runtime. This would allow me to complete the SocketManager instantiation at one point in the code and use that instance throughout my entire program (as it was already set as an dependency through the DI framework)? Is that the standard way to "inject" runtime dependencies or is it bad practice? A abstract factory

Something that has been bugging me since I read an answer on another stackoverflow question (the precise one eludes me now) where a user stated something like " If you're calling the Service Locator, you're doing it wrong. " It was someone with a high reputation (in the hundred thousands, I think) so I tend to think this person might know what they're talking about. I've been using DI for my projects since I first started learning about it and how well it relates to Unit Testing and what not. It's something I'm fairly comfortable with now and I think I know what I'm doing. However, there are a

I have an interface Fruit with two implementations Apple and Banana . I want to create a Fruit instance. The choice whether the concrete implementation should be an Apple or a Banana should be made by the user. I did not yet design the user interface, so there is no restriction how this choice is made by the user. I know there are the following options: usage of the abstract factory pattern usage of reflection to create an instance from a given class name usage of reflection to create an instance from a given class object What are the pros and cons of these options? Please note that while

Abstract When the design requires an "Abstract Factory Pattern" like stated by the [GoF] including several products and over some product families, then setting up an IoC can become a bit tricky. Especially when the specific factory implementations need to be dispatched by runtime parameters and shared among some subsequent components. Given the follwing API, i was trying to set up my IoC (Ninject in this case) to retrieve Configuration objects configured through a IConfigurationFactory . The configuration stores an IFactory instance whoose implementation is determined by a runtime parameter

I have a type Connections that requires asynchronous initialization. An instance of this type is consumed by several other types (e.g., Storage ), each of which also require asynchronous initialization (static, not per-instance, and these initializations also depend on Connections ). Finally, my logic types (e.g., Logic ) consumes these storage instances. Currently using Simple Injector. I've tried several different solutions, but there's always an antipattern present. Explicit Initialization (Temporal Coupling) The solution I'm currently using has the Temporal Coupling antipattern: public