Being a senior in college means many things. It means job interviews and upper-level classes, emotional instability and independent living. It also means countless hours of sitting in uninteresting classes whose sole purpose is to fulfill some graduation requirement. For me, that means lots of daydreaming--about anything other than that class. Recently however, during one daydream, I had a brain wave worth typing up: What's the deal with Object-Oriented Programming and Django?
The Convention
Browsing through the views.py file in just about any publicly-available Django-based application will almost certainly reveal nothing more than a bunch of functions. These functions are undeniably specialized: they take in an HttpRequest object (plus possibly some more information), and they return an HttpResponse object. Although these functions may be specialized, nevertheless they are still just functions.
This should come as no surprise to anyone who has used the framework--in fact, it's encouraged by common convention! Not only does the tutorial use plain functions for views, but also the Django Book, and just about every other application out there. The question now becomes "why"? Why, in a language that seems to be "objects all the way down", does a paradigm emerge for this domain (Django views) wherein functions are used almost exclusively in lieu of objects?
That's not entirely true, sir...
Any time a broad statement like "just about any" is used, the exceptions are what become interesting. The admin application (both newforms-admin and old) is probably the most notable and interesting exception to my earlier broad statement. It's interesting because it's Django's shining star! Other applications which use object orientation: databrowse and formtools. These are some great Django apps which use Object-Orientation in the views.
Looking at those apps which use OOP and those which don't reveals an interesting idea: those apps which strive to go above-and-beyond in terms of modularity tend to be those who end up using classes and their methods for views. Now this same functionality could be accomplished by using plain functions, but they haven't--their functionality was accomplished using classes and methods.
Please keep in mind that what I'm not trying to do is make a value judgement on Object-Oriented programming vs. functional programming vs. any other programming paradigm. Instead, I'm providing an observation about the emergence of a common practice, and trying to analyze its implications.
But wait!
What really is the difference between writing a plain function as a view and Object-Oriented programming? It's completely reasonable to argue that writing a plain function for a view is, in fact, Object-Oriented programming. All class methods take in self as their first positional argument, and all views take in request as their first positional argument. Taking in this argument allows access to state which would otherwise be difficult to access. Changing the order of urlpatterns is equivalent to changing the polymorphic properties of a class and dynamic method lookup.
In essence, one could argue that using a plain function as a view is strictly equivalent to writing a method on the HttpRequest object. Thinking about it in this way, writing a Django application is really nothing more than building up a monolithic HttpRequest object which the user can call different methods on using its API: the URL. To me, this is a really interesting idea!
Off My Rocker
This is the result of extreme classroom boredom--so maybe posts here will continue down this slightly-more-esoteric road for a while. But honestly this was an interesting thought-experiment, and I'd like to get some feedback on what people think as well. Am I totally off base with this analysis? Moreover, do you use true Python "classes" as your views? If so, what benefits does it bring to the table?
All Content
Oop is good for complex situations. When you can find actually complex web app that would really benefit from oop all the way let us know. As far as I have seen there has been none so far.
OOP in general is good. Once you start to think about objects and they being able to solve the problem at hand, everything becomes better arranged. And I dont refer to C++ OOP although even C++ way in this regard is better than C's way. (But C++ has a lot of other problems)
I am using plenty of objects, some big some small.
The complexity has nothing to do with it, maybe except really trivial things like displaying hello world.
Exactly; most Django apps are relatively simple and dont need OOP. I'm sure that EveryBlock probably does something more complex then function after function after function but for most applications it works well.
Check out http://www.rssmeme.com/ an app that I launched this week. Nothing more than 15 functions in a 161 line views.py
When I develop Django apps, I usually have several packages in my main app and each one of those has a views.py
That way, you could think of the views as methods of a package object.
But all in all I don't think using OO (in the strict sense, e.g. inheritance, polymorphism, etc.) translates well to views in Django, because requests are basically function calls. Your browser calls some function of a web server. So I think having them as functions is the way to go and with that you don't introduce any unnecessary complexity.
And besides, I've rarely shared any implementation between my views so I don't see how packing them up in OO would benefit me.
Think about the actual objects in a Django application: the model objects, request and response objects, etc. Just because views aren't encapsulated like an Object doesn't mean they should be. An action is not a noun, like a view is not an object.
Ooh, that's a really good point! Your argument is that a view is a verb, whereas a model is a noun? I guess I had forgotten about the "kingdowm of nouns" analogy from my OOP theory. I mostly agree.
Try to do some basic polymorphism with Django model objects, and you will notice that Django models are not object oriented, but record oriented.
I've used OOP in python and even within the Django framework. Its important to make a distinction between the application of different design patterns. Trying to cram OOP into the Django framework itself is putting the cart in front of the horse unless you can give a use case.
What requirement is there for OOP in Django?
The thing is, a view isn't an object, strictly speaking it's not a noun. It's a process preformed on a noun to transform it into another noun.
Each view every time it is called operates on different instance of an object and returns a different instance of another object.
It's a processor and not re-used later in the code and doesn't have attirbutes to be altered and methods to be re-called consistently.
Although you could have a class who's methods get called (rather than a module with functions) there is little use for it to be a class in actual function because it doesn't require persistence within the chain of events leading from a request to a response.
So all the work of making an class and an instance is kind of futile because it's not going to continue to exist after the view is returned.
However there is benefit sometimes, but I wouldn't shoot for bing OO just because it's "better" in an academic sort of way.
That said, there are times when it's a good idea.
I wish I'd read some of the other comments before I pitched in.
Compare Pylons, which uses Controller classes for no apparent reason whatsoever.
isn't a function in python a static method on the containing module object?