dependency injection in python

Dependency injection (DI) is a software reuse pattern, and has quite a lot of literature associated with it. Most of the videos you see on this topic start off with a small explanation of the SOLID principles. These principles are a set of guides to good object-oriented (OO) design. The 'D' in SOLID refers to dependency inversion - or dependency injection.

I found a very good video which explains the situation where we would actually go for this pattern. It is targeted to php audiences, but those who understand the basic OO principles can follow it easily.

Now python being a dynamic language the term dependency injection isn't as popular as it is in c# or java. This being because, python is a dynamic language. You assume can link to any bit of code at runtime and execute that functionality. If you have spawned up an instance of the python interpreter, you can write functions on the fly and execute them.



Python also has the notions of modules: they are mechanisms to enforce some modular approach to programming. This is also a way to accomplish reuse. You can write some functionality in them and import them into your main script or the interpreter instance, and use that functionality right away. In fact a lot of what is in the python standard library is reused this way.


Below is an example showing you how you can write your own module and import that one:



I have my own implementation of dependency injection hosted on github right now. It is inspired from spring.net library (.net library for di). But before you look at the code, and, if you are still unsure of how exactly python import statements work, you should look here.

Looking forward to interact with people on my google plus profile. Happy programming.

The loader pattern in JavaScript based applications

Most of the web applications you see are complex ajax driven applications. There is almost always an asynchronous call to a web service to get data; and having received that data we go forward with whatever our requirement. But consider a simple page such as this:
  This is a simple customer form which collects the customer personal details and credit card information. The form is useless. It needs vital data such as credit card types, titles, and, country values etc all available in the UI. But the catch here is we have to make api calls to the corresponding services to get it. But we'd have to wait to get the response from those three services.

This really stupid application is actually a mockup of what to expect in the real world. However, you may not agree. If your requirement ever runs on the same lines such as these, I assume you have the power to change the entire solution design. However, some ill-fated teams can't do anything to that regard. Hence we have something like this popup. But, please don't consider this rationale to be the reason behind the pattern.

Below we have kind of solved the problem of the above form becoming congruent for user input with a button click. This is just to demostrate the idea. I am using jQuery for my ajax calls, and jsFiddle apis to load some mock data. The point is I should not be able to do anything until the whole form is loaded. In practical implementations what happens on button click usually happens when the web page loads...



You can find the crux of the loader pattern in the loadForm function.