Data Mapper: Is my interpretation correct?

Question

I'm trying to confirm now, what I believe about the Data Mapper pattern. So here we go:

Section A: A Data Mapper is a class which is used to create, update and delete objects of another Class. Example: A class called Cat, and a Data Mapper called CatDataMapper. And a database table called cats. But it could also be an xml file called cats.xml, or an hard-coded array called cats. The whole point of that Data Mapper is to free the Business Logic which uses the Cat class from thinking about "how to get an exisiting cat", or "how to save a cat", "where to save a cat". As a user of the Data Mapper it looks like a blackbox with well-defined methods like getCat(int id), saveCat(Cat catObject), deleteCat(Cat catObject), and so on.

Section B: First I thought it would be clever if Cat inherits from CatDataMapper, because calling such functions then is a bit more convenient. For example, methods like catWithId(int id) could be static (class method) and return an instance of a Cat, initialized with data from anywhere. And when I work with a cat object in my code, I could simply call myCat->save(); to store it whereever the Data Mapper will store it (don't care where and how, the Data Mapper hides this complexity from the user).

In conclusion, I'm a little bit confused now ;) Do you think that Section A is valid for the Data Mapper pattern? And if I would do it additionaly as described in Section B, would that be bad? Why?

Answer 1

I think your Section A corresponds to the definiton of the Data Mapper pattern as given by Martin Fowler

Be careful with the details of your implementation language. In Section B having catWithId() be a static member of the cat class may interfere with polymorphic behavior of the method.

In java, the JVM will dispatch a static method based on the declared type of the reference.
Try this out:
1. create a class CatDataMapper with the static method catWithId(int id)
2. create a class Cat extending CatDataMapper that has the desired Business Logic behavior
3. subclass Cat with LoggedCat that logs all activity, including the activity from CatDataMapper
4. do Cat foo = new LoggedCat()
5. do Cat bar = foo.catWithId(5)

note which method is called, it should be the static method of CatDataMapper not the static method of LoggedCat

http://faq.javaranch.com/view?OverridingVsHiding gives a more in-depth discussion of this.

Answer 2

I think this is an OK approach. Aside from the naming conventions used, you're following a well known Data Access pattern here and you're allowing the users of the Cat objects to perform CRUD operations without having to talk to the CatDataMapper which is always a plus in my book.

I would usggest looking at Spring Container technology for this if you're in the java world.