7

I have an app in Django that expects to get a record with the fields email, first_name, and last_name.

However, sometimes I want to be able to send it something that isn't actually a record but behaves like one (in that it has the necessary fields as attributes), like so:

class FakeRecord(object):
    def __init__(self, email, first_name=None, last_name=None):
        self.email = email
        self.first_name = first_name
        self.last_name = last_name

I'm wondering if there is a standard name for this kind of object or if FakeRecord works as the name for this class.

More generally, is there a name for a class that stands in for or behaves similarly to another class? Is there a standard implementation/design pattern?

Further clarification

For the purposes of my app, basically I have a utility function that sends an email to a recipient. The recipient can be any Django record so long as it has an email address, a first name, and a last name.

However, sometimes the app sends a one-off mailing to some given e-mail address that doesn't have a record. In those cases, I simply create a FakeRecord with the email address (and first name/last name if available), and send that in instead.

Since the utility function itself doesn't do anything with the record other than retrieving the attributes, none of the other db functionality of a Django record object is needed.

Jordan Reiter
  • 623
  • 5
  • 13

2 Answers2

12

It sure looks like a Mock.

While often used for testing, it's also sensible in a Duck-typed language to mock other class definitions.

You've got two classes which are both implementations of a common interface. This is polymorphism in action. There's not much of "standard formal" name for it because it's just OO programming.

In Python, because there's no formal requirement for a separate interface class, these are just polymorphic classes.

You could call them "Polymorphs" or "Alternative Implementations".

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • Sounds like its primary use is in testing, but I'll take it. – Jordan Reiter Oct 19 '11 at 19:22
  • +1 Looks like a Mock Object. Which are commonly used to remove dependencies in unit testing. – Heath Lilley Oct 19 '11 at 19:24
  • @JordanReiter: You can can also call it a "dummy" object if "mock" sounds too much like testing and you're not using it for testing. – FrustratedWithFormsDesigner Oct 19 '11 at 19:33
  • I'd avoid "dummy"; that often implies that it's missing some functionality. – S.Lott Oct 19 '11 at 19:36
  • 1
    Name it for what it does. If its a testing mock, name it MockRecord. If its a production object that takes record data and does Foo with it, name it FooRecord. You don't want to have names like "Fake" in production code, because, A) other developers (which includes you six months from now when you forgot what you did) won't know what the class is for, and B) if it ever appears in an error message it might give your users the wrong impression. – kylben Oct 19 '11 at 20:49
2

According to Martin Fowler, fake is pretty accurate:

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

http://martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs

Gyan aka Gary Buyn
  • 2,775
  • 19
  • 17
  • http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html – Oded Oct 19 '11 at 20:01
  • According to Martin Fowler, it would probably be a Stub in this case. Fakes are used for example, to host a test server, which is actually a server, using sockets, etc, only it doesn't do heavy calculating. – Yam Marcovic Oct 19 '11 at 23:13