Hi Joseph,
the basic wiring instances together is done via the assignment operator:
"=". Like: queue._api = foo. Now, the "queue" knows about its API instance.
Question now is, when do you do "="?
On 18.09.2015 23:43, Joseph L. Casale wrote:
This is where I am going, but how do you perform dependency injection
in Python?
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.
But if you are interesting the DI in Python in general, I think you
would love to read those two resources:
http://www.aleax.it/yt_pydi.pdf
http://code.activestate.com/recipes/413268/
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 *when finally you
know where you application is going*. Otherwise, it might turn out to be
a waste of resources.
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*
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).
As usual, somebody *needs**to know*. 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*.***
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).
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.
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).
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.
Why do you want to store the objects in files? Caching?
I know, tough to do in
Python, but its what I am used to.
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. :)
Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list
