A data pattern

A useful data pattern one can implement is to extract all behavioral features from the abstraction in question, and into a new behavioral super class. This trivial pattern will allow several data implementations of the class inherit the same behavior interface.

For example, here is a simplistic view of this pattern in the context of a blogging system.




Here, we have three classes; BlogBehavior, BlogDB, and BlogMemory. BlogBehavior defines the methods involved with what a blog does. BlogDB defines data access methods for interacting with the database. BlogMemory defines data access methods that will store and retrieve attributes in memory.

Methods defined by instances of BlogDB and BlogMemory may be invoked by methods in BlogBehavior. This would be ideal, because which of the two data instances is being used in the context of the blog system doesn't matter.

The concept of separating abstrations based on storage location, data access technonlogy (same database, different API), is not new. I have witnessed several ocasions, however, where the same behavior is not generalized. I think this is an important practice to keep in touch with when using object technology.