<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Joseph,<br>
<br>
the basic wiring instances together is done via the assignment
operator: "=". Like: queue._api = foo. Now, the "queue" knows about
its API instance.<br>
<br>
Question now is, when do you do "="?<br>
<br>
<div class="moz-cite-prefix">On 18.09.2015 23:43, Joseph L. Casale
wrote:<br>
</div>
<blockquote cite="mid:1442612592952.36609@activenetwerx.com"
type="cite">
<pre wrap="">This is where I am going, but how do you perform dependency injection
in Python? </pre>
</blockquote>
<br>
I am uncertain how large the application you want to build is
supposed to be. I would definitely would start with less code
(tighter coupled) which is easier to maintain in the first run.<br>
<br>
But if you are interesting the DI in Python in general, I think you
would love to read those two resources:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.aleax.it/yt_pydi.pdf">http://www.aleax.it/yt_pydi.pdf</a><br>
<a class="moz-txt-link-freetext" href="http://code.activestate.com/recipes/413268/">http://code.activestate.com/recipes/413268/</a><br>
<br>
I am not saying you shouldn't do DI, but it's easier to tight-couple
things and make them more flexible in the aftermath <b>when finally
you know where you application is going</b>. Otherwise, it might
turn out to be a waste of resources.<br>
<br>
<blockquote cite="mid:1442612592952.36609@activenetwerx.com"
type="cite">
<blockquote type="cite">
<pre wrap="">It's perfectly fine to add a "secret" API instance to the object. It's
called aspect-oriented programming. You remove the aspect of how to
correctly manage an API instance and put that knowledge into a separate
piece of code. *thumbs up*
</pre>
</blockquote>
<pre wrap="">
Yea, I am glad you agree:) Its a model I certainly subscribe to. I just don't
know how to make the disparate case "know" of the foo instance when
foo didn't instantiate it (which gives the injection opportunity).
</pre>
</blockquote>
<br>
As usual, somebody <b>needs</b><b> to know</b>. So, if the first
version is only working hard-coupled because foo instantiated the
queues, the second version then would, for example, assign the
APIWrapper class instead of an APIWrapper instance to the _api
attribute of all queue instances. The class could then work as a
lookup/factory method<b>.</b><b></b><br>
<br>
If that is still not flexible enough and you find Queue and
APIWrapper is still too much coupled, you can then refactor that out
into a third module which is responsible only for wiring the
instances together (or use the recipe).<br>
<br>
But remember, you increase the complexity more and more and you
better decide whether it's worth it, taking maintenance and future
development into account. <br>
<br>
I might reiterate here: I don't know of the scale of your
application but if it is from scratch, you better start with tighter
coupling and remove it bit by bit later, when you know where the
journey goes AND if the tight coupling causes issues. It does not
make sense to solve non-issues (at least economically).<br>
<br>
<blockquote cite="mid:1442612592952.36609@activenetwerx.com"
type="cite">
<pre wrap="">That foo instance also serves of a starting point to make the GET type queries.
How would you go about making disparate case lookup a handle, especially
when I insist on placing all the objects in their files.</pre>
</blockquote>
<br>
Why do you want to store the objects in files? Caching?<br>
<br>
<blockquote cite="mid:1442612592952.36609@activenetwerx.com"
type="cite">
<pre wrap="">I know, tough to do in
Python, but its what I am used to.</pre>
</blockquote>
<br>
That's alright. Your thinking will change the longer you use Python.
You are going to strive for the simples (non-complex), shortest,
direct and most comprehensive solution. It's a development; don't
forget what you've learned but be open for the Python style. :)<br>
<br>
<br>
Best,<br>
Sven<br>
</body>
</html>