Class views in Django
<p><a href="http://www.djangoproject.com/">Django</a> view points to a function, which can be a problem if you want to change only a bit of functionality. Yes, I could have million keyword arguments and even more if statements in the function, but I was thinking more of an object oriented approach.</p>

<p>For example, I have a page that displays a user. This page is very similar to page that displays a group, but it's still not so similar to just use another data model. Group also has members etc...</p>

<p>One way would be to point views to class methods and then extend that class. Has anyone tried this approach or has any other idea? </p>
<p>I've created and used my own generic view classes, defining <strong><code>__call__</code></strong> so an instance of the class is callable.  I really like it; while Django's generic views allow some customization through keyword arguments, OO generic views (if their behavior is split into a number of separate methods) can have much more fine-grained customization via subclassing, which lets me repeat myself a lot less.  (I get tired of rewriting the same create/update view logic anytime I need to tweak something Django's generic views don't quite allow).</p>

<p>I've posted some code at <a href="http://www.djangosnippets.org/snippets/1009/">djangosnippets.org</a>.</p>

<p>The only real downside I see is the proliferation of internal method calls, which may impact performance somewhat. I don't think this is much of a concern; it's rare that Python code execution would be your performance bottleneck in a web app.</p>

<p><strong>UPDATE</strong>: Django's own <a href="http://docs.djangoproject.com/en/dev/topics/class-based-views/">generic views</a> are now class-based.</p>

<p><strong>UPDATE</strong>: FWIW, I've changed my opinion on class-based views since this answer was written. After having used them extensively on a couple of projects, I feel they tend to lead to code that is satisfyingly DRY to write, but very hard to read and maintain later, because functionality is spread across so many different places, and subclasses are so dependent on every implementation detail of the superclasses and mixins. I now feel that <a href="https://docs.djangoproject.com/en/dev/ref/template-response/">TemplateResponse</a> and view decorators is a better answer for decomposing view code.</p>
