What is the proper name for this design pattern in Python?

Question

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):
        self.resource.post(person.data())

    def get(self):
        pass

    def update(self):
        pass

    def delete(self):
        pass


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)

Answer 1

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.

Answer 2

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):
    self.resource.create(...)

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.

Answer 3

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.

Answer 4

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

https://docs.djangoproject.com/en/dev/topics/db/managers/

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.