Thank you for taking the time to asnwer my concerns. I find that all of the resolutions you offered were too much sacrificy for my taste and actually summarize why I always prefer DI over Service Locator(I am not sure what I was thinking but I realized outputselect and saveoutput methods are actually participatng in a service locator pattern. Have to read blogs in the morning, when fresh …). Anyways, thanx for the discussion, I am always curios about other people’s perspective, so keep these posts coming

1) make a module call it “IoCConfig” and use it the same way you’d do your IoC registration. This same issue could be related to how you use an IoC container. Use it in a dumb way and you’ll have to recall the code over and over again.

2)Again this is the same issue you have with IoC controllers, you have multiple implementations of the same interface, you have to make special allowances for custom resolution. _in either approach you have to do custom code to switch which interface implementation is in use_. I made Output a specific empty class for a reason, its a good stand in for an interface (and when people see Output has no code body it especially hits home that a “strategy” needs to be selected”. Finally in this case I’d suggest a factory that hands off the correct instance of said class at a given time..which I’d be inclined to use as a solution in static languages in complex enough cases.

3) See #2 , again custom factories are more suitable here, in python or C#. The reason IoC containers tend to handle this is because its the only place you typically get access to your “entire run time” barring some magic hackery in the CLR with the profiler. When you _already_ have access to your entire runtime, you can just use the natural methods to do these things.

4) No I’m assuming my types have a constructor with the same signature (important distinction,and when not using DI, your constructors are much more manageable). If I really need to do dynamic resolution of types with differing signatures I again wrap this in a custom factory and it would have a similar algorithm to what you use in an IoC container (if you’ve never written one I highly encourage it, its not hard and it gives you a unique perspective), but I’d have no desire to put my entire runtime in it, or maintain placing my entire runtime in the IoC. only the bits I care about that need this special custom functionality, and its rare at best.

PS I know you said ignore AOP but as a side note I’m not advocating decorators, and i think by themselves are a poor use of AOP in my opinion (same way attributes are in C#). I just used the wrap decorator in my code to apply interceptors on the fly (which can be done by rule matching and I only wrap what I want), otherwise the approach is I feel a Python equivalent to Windsor’s internal implementation of DynProxy and Interceptors.

I think I phrased my question the wrong way. I will try again, but this time I will list the issues I have with the code above:

1. the code is hard-coded to instantiating the type stored in outputlib.Output. If I have to reuse this code again I have to make this module and variable existent and store the type there

2. if I want to make two instances of the code (in this case it looks like a method) that use two different methods of rendering I have to change renderers in outputlib.Output in between (or something like that) the method calls

3. In multi-threaded scenarios (no idea how is threading in python) point #2 becomes something I am not ready to deal with

4. This one is a bit on the side, but you are also instantiating the type in your method assuming it takes no parameters in the constructor.

My current thinking is that DI takes care of these things no metter the language. You could do exactly the same thing you have done here but in C# and it will be equally mockable and testable, it’s just that I think it will be a lot cleaner if you just passed that renderer instance as a parameter

What am I missing Ryan?

Best regards,

Petar

P.S. Let’s leave AOP on the side for now, python decorators are interesting approach but I am still not completely sure how I feel about them

What is the point of dependency injection and Inversion of Control? We get testability, easy ability to override behavior in our _actual_ codebase, If you’re doing DI and IoC for any other reason I’m glad to recant my recant and hear what it is.

Why do we use IoC containers themselves? having a nice thing to prevent us from having to write a ton of factory classes, since we have to use DI to keep ourselves from tightly coupling our code. Also, we get for low cost nice things like AOP, and contextual resolution.

In dynamic languages you get all that _even when you call new_ . You still get testability and mockability, look at the examples above, I’m actually overriding the entire class object, so now _every_ time you call new on that class that code you will get the new value. This sort of functionality you get by using DI, dynproxy, and intercepters. Which involves a big chunk of code.

Now if I can _STILL_ have testability that’s even stronger than the best mocking libraries in static languages, have low coupling always, and I can in a few lines of code apply logging, security, to entire modules and code bases (which is why I’m using an IoC container in the first place) why would I want to have another IoC container?

I am also in the process of learning Python/Django and trying to let go of my “static thinking” but I am not sure I completely understand your point. Looking at the registration sample with the renderers I can see the registration part but I am not seeing how is the dependency injection part going to happen. Let’s forget about the service locator for now, shall we

Mental Note to self: self, stop fooling around and check out python spring.

Besrt regards,

Petar

When you call it “contextual” it sounded so much fancier and thought there might be some cool magic I didn’t know about.

Can you explain how you achieve this?

“give me hooks for contextual resolution”

You have “strategy” without explicitly
making it clear, it’s like one big global IoC container.