Take the 2-minute tour ×


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.

add comment

4 Answers

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
show 1 more comment

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
add comment

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
add comment





share|improve this answer
add comment

Your Answer


