Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In Python, is the proper name for the PersonXXX class below PersonProxy, PersonInterface, etc?

import rest

class  PersonXXX(object):

    def __init__(self,db_url):
        self.resource = rest.Resource(db_url)

    def create(self,person):

    def get(self):

    def update(self):

    def delete(self):

class Person(object):

    def __init__(self,name, age):
        self.name = name
        self.age = age

    def data(self):
        return dict(name=self.name,age=self.age)
share|improve this question

migrated from stackoverflow.com Jun 29 '11 at 0:21

This question came from our site for professional and enthusiast programmers.

5 Answers 5

up vote 7 down vote accepted

EDIT: In a comment to another answer the OP wrote:

I've gone back and forth between a single-class design and a two-class design as the one shown in my question. I'm back on the two-class approach b/c something needs to contain the run-time configurable resource object prior to the Person object being created.

This scenario clarify that the design-patter should be the Proxy (a.k.a. Surrogate). The original description from the GOF says:

...one reason for controlling access to an object is to defer the full cost of its creation and initialization until we actually need to use it... the solution is to use another object, an image proxy, that acts as a stand-in for the real image.

Following is the original answer (still valid in many ways, this is why I am leaving it)

Thinking to architectural patterns, and more specifically to the Model-View-Controller: PersonController, as it looks like the Person class will hold data (and you might have a View displaying the data in some way.

Thinking to design patterns, the name would really derive from the use you make of the class.

It could be an Adapter because it converts the native interface of an object to a different one, or could be a Flyweight if you use it for all persons adding a lot of heavy methods and data to it and keeping the underlaying Person as light as possible or still a Proxy if you would implement some sort of logic in how and if users could access the underlying instance of Person.

I can only speak for myself, but I often find myself to blend different design patterns together, according to the specificities of the software I am coding.

share|improve this answer
+1 agree esp. if he is doing web. –  Nix Jun 28 '11 at 20:18
This is for a persistence framework that can be used for anything. –  espeed Jun 28 '11 at 20:19
@edspeed - Nix meant especially if he is doing web. In web development the MVC pattern (in a plethora of different flavours) is pretty much a standard (think Ruby on rails, CakePHP, Django, etc...). The architectural pattern is also tipically used in desktop applications with a GUI, but there is nothing preventing is adoption in other situations, if it's a good fit. –  mac Jun 28 '11 at 20:37
@mac Thanks for the feedback. I've also been trying to get feedback on if this two-class design the right approach (see my comment to Daniel below). In another version of this design, the XXX class is not there and everything is in the Person class, using classmethods to interact with the REST resource. This worked great when there was only 1 REST resource but breaks down when you allow users to specify the db_url at runtime. –  espeed Jun 28 '11 at 20:47
@espeed - I can't say for sure because I don't know your design, but have you thought about a single class with lazy load operations? In other words: you store the DB name at initialisation, but attempt to connect to it only when a "getter" method is invoked? –  mac Jun 28 '11 at 20:56

It is a Handler, right? It is the thing that mediates the interpretation of Person objects for use by the REST interface.

It can be called any one of a number of more specialized things. But that is its generic name, if you want to look at it from the Person-object's point of view, rather than from the REST system's.

It is not a Proxy because it does not pretend to be a Person object, it is an Interface but on REST not on Person, and it fails to inherit this formally, so it is only kind of a 'duck' Interface. It does not manage the created Person objects, nor does it collect them, and it is not part of one. So that kills most of the answers floated before.

Presumably it will be consumed by something that coordinates when to send stuff to the external system, or it will be used as an intermediary by code that is focused on the REST system and not on Person objects (I am synchronizing various things, and this one is a Person).

share|improve this answer

Django calls this a Manager. Your PersonXXX class exists at Person.objects, while Person itself encapsulates a single person record.


Django's ORM is a joy to work with, and highly respected. Coming from PHP/spaghetti, it was the first piece of code I ever considered "beautiful."

Since you're designing a persistence framework, I highly recommend you read about/play with it.

share|improve this answer
Thank you for that pointer. One of the reasons I liked the single-class approach is it allowed me to subclass models and do stuff like: def get(id): #code-goes-here return self(results) and I didn't want to give up the simplicity of return self(results). But, in other places, such as the query module, I pass in the "model" classes so the results could be initialized to the proper class. Evidently this is what Django is doing too. I finally bit the bullet and switched back to the two class approach where a proxy does the get instead of a subclass and am passing the model class to proxy. –  espeed Jun 29 '11 at 20:12

I'm not at all sure there is a name for it in Python, simply because it doesn't seem very Pythonic.

Python doesn't insist on classes for everything. The Person is correctly a class, because it stores information about an individual person. But the XXX doesn't seem to have any particular need to be a separate class - if it's a set of functions that define interaction with the Person data, it can either be a mixin that is inherited into the Person class itself, or simply a separate module that collects those functions together.

share|improve this answer
I've gone back and forth between a single-class design and a two-class design as the one shown in my question. I'm back on the two-class approach b/c something needs to contain the run-time configurable resource object prior to the Person object being created. To see what I'm talking about, see my question from last night (stackoverflow.com/questions/6501193/…). –  espeed Jun 28 '11 at 20:37
@espeed - from what you say in this comment, I would say that the right name is therefore Proxy/Surrogate. I will update my answer. –  mac Jun 28 '11 at 20:45

I do not think Interface or Proxy are good fits for what you are trying to achieve. Interface is not a good name because it simply isn't an iterface, and proxy is not a good fit because its not really serving as a wrapper.

If your code was more like this:

def create(self,person):

I would be more accepting of the name PersonProxy.

I would argue Repository

PersonRespository because it semi resembles a collection interface, and sure smells like its going to be in charge of the object.

Another name could be PersonDAO because it is also serving as an access interface for the person object.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.