Class providing methods inherited into class providing underlying data - How is that called?
<p>I have a class <code>Library</code> which defines some methods on - kind of - abstract data. This class is then inherited into a class <code>A</code> or <code>B</code> that actually defines the data. The intention is to reuse <code>Library</code> with different underlying data storage models.</p>

<p>In Python:</p>

<pre><code>class Library:
    def meth1(self, ...):
      return ...
    def meth2(self, ...):
      return ...
    def compute_property1(...):
      return ...
    def compute_property2(...):
      return ...

class B(Library):
    property1 = property(lambda s: s.compute_property1()) #plain property
    property1 = property(lambda s: s.compute_property2()) #plain property

class A(Library):
    property1 = my_property_with_fancy_caching_and_compression_and_stuff(....)
    property1 = my_property_with_fancy_caching_and_compression_and_stuff(....)
</code></pre>

<p>Is this pattern a well-known design approach? Does it have a name? Is there a recommended name for <code>Library</code>?</p>

<p>Your example is leveraging Python's Multiple inheritance mechanism, whereby you add methods from a methods-only, data-free, abstract class <code>A</code>, to one (or several) data-oriented, dumb concrete class <code>B</code>.</p>

<p>As it separates data-storing (representation) from functionality (methods), it is very <strong>close to a mixin</strong> as <a href="http://stackoverflow.com/users/41316/bruno-desthuilliers">Bruno</a> commented, but with the distinction that such pattern usually brings both data storage <em>and</em> functionality. This difference in your pattern makes it not completely <a href="https://en.wikipedia.org/wiki/Object-oriented_programming" rel="nofollow">OOP</a> (where an object is supposed to bring both) but is <strong>reminiscent of the <a href="https://en.wikipedia.org/wiki/Aspect-oriented_programming" rel="nofollow">Aspect-Oriented</a> paradigm</strong>.</p>

<p>If I were to describe this mechanism in OOP, I'd call class <code>A</code> an <strong>interface with default methods</strong>. That would carry the ability to import anywhere some methods implementations, but <em>no fields</em>. And I would call class <code>B</code> <a href="https://en.wikipedia.org/wiki/Data_access_object" rel="nofollow">Data Access Object</a></p>

<p><em>Note:</em> If you intend to do so for several interfaces (<em>e.g.</em>, if you were to split your <code>meth1()</code> and <code>compute_priority_1()</code>from <code>meth2()</code> and <code>comute_priority_2()</code> from each other, and place them in two separate interfaces), then that would follow <a href="https://en.wikipedia.org/wiki/Interface_segregation_principle" rel="nofollow">Interface Segregation Principle</a>.</p>

python design-patterns