Design question about storrs and drivers #123
Description
I am curious about your overall design considerations of the storr/driver implementation, how well you think they played out, and what you might do differently if you were to rewrite storr today.
In #122, the clear() method of the base storr class first looks for a clear() method in the driver and defaults to a backup method if none is found. This would be far more natural with sub-classes and inheritance. However, I am not saying sub-classes would have been better. Far from it: here in drake, I too use the decorator pattern for storrs. In drake's case, I thought object composition would be less brittle than inheritance for the implementation of specialized formats, given that the base class comes from another package, and I am satisfied with the result.
Was the thought process similar for storr itself? Did you originally envision external packages like thor and judge object composition to be better than exposing a class definition?