Should factoring out repetition apply to interfaces and not just implementation?
--------
Under ReinventingTheDatabaseInApplication, TopMind suggests that relational design tends to move many "database-like verbs" out of multiple spots and into the DataBase, simplifying interfaces by delegating such tasks, or at least their operations, to the database instead of specific interfaces.

For example, if we look at a bunch of classes and see:

  class A {
    method foo()....
    method bar()....
    method glog()....
    ....
  }
  class B {
    method foo()....
    method bar()....
    method glog()....
    ....
  }
  class C {
    method foo()....
    method bar()....
    method glog()....
    ....
  }

Unless the methods' implementation is very different, then why not refactor them to some common spot such as the/a parent or another class? This is what TopMind feels databases do for what he terms DatabaseVerbs more or less.

The interfaces should be factored if, and only if, doing so implies a type relationship between A, B, and C (e.g., instances of A, B, and C are, or at least can be thought of as, of type T).  For example,

  class C: public FooBarGlogable {
    ...
  }

implies that all instances of C are FooBarGlogable, and thus, anything which accepts such a thing can accept instances of C too.

* ''This assumes that variations should be modeled as sub-types. IS-A variation modeling has problems in many cases. See LimitsOfHierarchies.''
* This has nothing to do with hierarchies, and everything to do with set membership.  An interface, by definition, is a self-standing abstract base class with no implementation.  The implementation for class C still provides the implementation for the interface.  Interface implementation does not conform to hierarchy, except insofar as implementing one interface presupposed the implementation of another.
* ''IS-A is hierarchical. Now, there are things such as multiple inheritance and mixins, but they are messy. They are force-bending something originally designed for IS-A into something else. Best to start with sets and set-friendly tools. It's cleaner then retrofitting (traditional) types. (If you start with sets and predicts as your variation-management tool and building blocks, it will naturally lead to something relational- or ProLog-like.)''
* IS-A is not hierarchial, it's a truth statement.  Inheritance hierarchies, which you're thinking of, is only ''one way to implement'' an is-a relationship.  Multiple interface inheritance, MixIn''''''s, and TypeClasses are different methods of achieving the is-a goal without expressly imposing a hierarchy.
* ''Perhaps I should have said, DAG-like. Anyhow, there are different ways to approach the same issue/thing. The app-language-centric approach to handling large collections or "lists" is not the best in my opinion because they have no or poor meta abilities. Perhaps its a matter of style preference. In practice, I don't see a lot of interface factoring in OOP circles. Related: JavaIoClassesAreImpossibleToUnderstand.''

''That is an interesting question. Can a root class have them built in so that all classes can automatically have certain operations, or must the implementation still be repeated or implemented differently for each one? Why would they have to be different? For example, can DatabaseVerbs be put into a master parent class in some languages to make collections of objects automatically have database-like abilities? -- top''

That is exactly what ObjectRelationalMapping frameworks, especially ones likes JDO,  typically do.

They do it by code generation for the most part. I tend toward CodeGenerationIsaDesignSmell. That is not "factoring", but automated replication of a similar pattern(s). It is not OnceAndOnlyOnce, but rather automated copy-and-paste ''(so are compilers)''. Also, ORmapping tools are often seen as a compromise between two paradigms with different philosophies. Few would call them the ideal situation (at least that is the impression I get) and often require a lot of labor-intensive tweaking. And they encourage object-at-a-time thinking rather than leveraging the aggregation and bulk-handling power of query languages to do most of the work for you. Java programmers tend to use the DB as merely a "dumb" filing system.

-----

Although in the case of databases I think such is a good thing, I wonder if there is not a bigger principle or set of principles to act as guides. Does OnceAndOnlyOnce apply to just implementation?

----------
CategoryAbstraction, CategoryInterface, CategoryPolymorphism