Interface Factoring

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.

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


EditText of this page (last edited January 9, 2013) or FindPage with title or text search