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?