Different repository implementations?

[ytsejam78]

This was briefly discussed between Gabriel and I. Other opinions are welcome.
If we model the storing, purging, updating and finding, it seems the repository could be implemented with a single class (goodbye hierarchy).

Two main points make me think this:

1. Currently the superclass defines subclass responsibilities which do not make sense for all subclasses (e.g. #configureMappingsIn:)
2. It defines common behavior which could be extracted to other objects which are easy to create (as I said, the actions for store, purge, update and access the repository elements)

I think this idea is worth trying and not too difficult to try in this early stage of development.
For example, the store action which is the same for all implementations, would be another object which when evaluated, it would perform the assertion for conflict check (which will be a collaboration with the conflict checking strategy which is already a different object) and then store the object.

It feels we could achieve same behavior with one less hierarchy and creating more reusable objects.
Not sure if transaction management gets in the way for all implementations other than InMemory variant, but I am sure it could be solved with more object composition.