Python/Django and services as classes

Question

Are there any conventions on how to implement services in Django? Coming from a Java background, we create services for business logic and we "inject" them wherever we need them. Not sure if I'm using python/django the wrong way, but I need to connect to a 3rd party API, so I'm using an api_service.py file to do that. The question is, I want to define this service as a class, and in Java, I can inject this class wherever I need it and it acts more or less like a singleton. Is there something like this I can use with Django or should I build the service as a singleton and get the instance somewhere or even have just separate functions and no classes?

Answer 1

Adding to the answer given by bruno desthuilliers and TreantBG.

There are certain questions that you can ask about the requirements. For example one question could be, does the api being called change with different type of objects ?

If the api doesn't change, you will probably be okay with keeping it as a method in some file or class.

If it does change, such that you are calling API 1 for some scenario, API 2 for some and so on and so forth, you will likely be better off with moving/abstracting this logic out to some class (from a better code organisation point of view).

PS: Python allows you to be as flexible as you want when it comes to code organisation. It's really upto you to decide on how you want to organise the code.

Answer 2

TL;DR It's hard to tell without more details but chances are you only need a mere module with a couple plain functions or at most just a couple simple classes.

Longest answer:

Python is not Java. You can of course (technically I mean) use Java-ish designs, but this is usually not the best thing to do.

Your description of the problem to solve is a bit too vague to come with a concrete answer, but we can at least give you a few hints and pointers (no pun intended):

1/ Everything is an object

In python, everything (well, everything you can find on the RHS of an assignment that is) is an object, including modules, classes, functions and methods.

One of the consequences is that you don't need any complex framework for dependency injection - you just pass the desired object (module, class, function, method, whatever) as argument and you're done.

Another consequence is that you don't necessarily need classes for everything - a plain function or module can be just enough.

A typical use case is the strategy pattern, which, in Python, is most often implemented using a mere callback function (or any other callable FWIW).

2/ a python module is a singleton.

As stated above, at runtime a python module is an object (of type module) whose attributes are the names defined at the module's top-level.

Except for some (pathological) corner cases, a python module is only imported once for a given process and is garanteed to be unique. Combined with the fact that python's "global" scope is really only "module-level" global, this make modules proper singletons, so this design pattern is actually already builtin.

3/ a python class is (almost) a singleton

Python classes are objects too (instance of type type, directly or indirectly), and python has classmethods (methods that act on the class itself instead of acting on the current instance) and class-level attributes (attributes that belong to the class object itself, not to it's instances), so if you write a class that only has classmethods and class attributes, you technically have a singleton - and you can use this class either directly or thru instances without any difference since classmethods can be called on instances too.

The main difference here wrt/ "modules as singletons" is that with classes you can use inheritance...

4/ python has callables

Python has the concept of "callable" objects. A "callable" is an object whose class implements the __call__() operator), and each such object can be called as if it was a function.

This means that you can not only use functions as objects but also use objects as functions - IOW, the "functor" pattern is builtin. This makes it very easy to "capture" some context in one part of the code and use this context for computations in another part.

5/ a python class is a factory

Python has no new keyword. Pythonc classes are callables, and instanciation is done by just calling the class.

This means that you can actually use a class or function the same way to get an instance, so the "factory" pattern is also builtin.

6/ python has computed attributes

and beside the most obvious application (replacing a public attribute by a pair of getter/setter without breaking client code), this - combined with other features like callables etc - can prove to be very powerful. As a matter of fact, that's how functions defined in a class become methods

7/ Python is dynamic

Python's objects are (usually) dict-based (there are exceptions but those are few and mostly low-level C-coded classes), which means you can dynamically add / replace (and even remove) attributes and methods (since methods are attributes) on a per-instance or per-class basis.

While this is not a feature you want to use without reasons, it's still a very powerful one as it allows to dynamically customize an object (remember that classes are objects too), allowing for more complex objects and classes creation schemes than what you can do in a static language.

But Python's dynamic nature goes even further - you can use class decorators and/or metaclasses to taylor the creation of a class object (you may want to have a look at Django models source code for a concrete example), or even just dynamically create a new class using it's metaclass and a dict of functions and other class-level attributes.

Here again, this can really make seemingly complex issues a breeze to solve (and avoid a lot of boilerplate code).

Actually, Python exposes and lets you hook into most of it's inners (object model, attribute resolution rules, import mechanism etc), so once you understand the whole design and how everything fits together you really have the hand on most aspects of your code at runtime.

Python is not Java

Now I understand that all of this looks a bit like a vendor's catalog, but the point is highlight how Python differs from Java and why canonical Java solutions - or (at least) canonical Java implementations of those solutions - usually don't port well to the Python world. It's not that they don't work at all, just that Python usually has more straightforward (and much simpler IMHO) ways to implement common (and less common) design patterns.

wrt/ your concrete use case, you will have to post a much more detailed description, but "connecting to a 3rd part API" (I assume a REST api ?) from a Django project is so trivial that it really doesn't warrant much design considerations by itself.

Answer 3

In Python you can write the same as Java program structure. You don't need to be so strongly typed but you can. I'm using types when creating common classes and libraries that are used across multiple scripts. Here you can read about Python typing

You can do the same here in Python. Define your class in package (folder) called services

Then if you want singleton you can do like that:

class Service(object):
instance = None
def __new__(cls):
    if cls.instance is not None:
        return cls.instance
    else:
        inst = cls.instance = super(Service, cls).__new__()
        return inst

And now you import it wherever you want in the rest of the code

from services import Service
Service().do_action()