Service Abstraction

Polymorphism is primarily used to create an abstraction that can be implemented in several ways. An abstraction that I have created many times is a service abstraction. For instance, you may want to define a storage service abstraction modeled as a key-value store for binary objects. You could then implement it for S3, CloudFiles, and Azure. For use in tests, you could even implement a local filesystem backend.

My abstraction will consist of five functions: connect, get, put, delete, and close. You call connect to construct a service object. The service object will be used with get to fetch an object from the store, put to store an object in the store, delete to delete an object from the store, and close to clean up the service object.

There are a couple of different ways of defining and implementing this abstraction. Each will have its own advantages and disadvantages. Let's first take a look at them, and then I will pick them apart for some design principles...