Inheriting from an ancestor genealogy

In object-oriented software development creating classes in a genealogy (inheritance) tree has been common practice for almost two decades. Children objects inherit attributes (data) and behavior (code) from their mother and grandmothers over several inheritance levels. This is a key internal feature of every Java or Smalltalk and many C++ applications. It's just state-of-the-art!

But why hasn't this been used for application data? Why not for visualization objects, for frames, tables, containers, styles etc.? This would substantially ease the creation and maintenance of complex data structures as used in a publishing system. And it would show the entire system much better and clearer arranged.

Multi-level inheritance for all object types
Well, ElePub has full multi-level inheritance from a genealogy tree both for content data and for publishing and visualization objects - as the first publishing system at all (to the best of our knowledge). And in case of ElePub this is really true inheritance, not referencing templates or duplicating with references nor using templates, which are copied! Because inheritance is far superior to poying or recerencing templates.

There is one common generic Sarah object, a great grand-mother, at the very top of the inheritance tree, from which all others inherit. Depending on the needed attributes, in this example there is first a distinction between alphanumeric ("speaking") article numbers and those used only internally because their behavior differs substantially from one another. On the third level there are distinctions made on the structure and logical ownership of an article number, which influences their behavior and/or structure. They all inherit from one common mother object and share most of its attributes and behavior.

This is just a very much simplified example for the construction of inheritance trees, which in reality are much more complex and often spread over 10 or more inheritance levels. This is the best way to achieve an extreme modularity coupled with a great degree of abstraction and resulting simply in less code, less development effort, less bugs and less maintenance.

Re-using objects is very much better and far more intelligent than making new objects!

Inheriting is far superior to copying
Copying objects is just bad and wrong! Because it creates independent duplicate objects, which are much harder to maintain, which are not linked or connected to their original source and which will have to be changed one by one whenever something must be changed. Copying creates chaos, wastes your time, steals your money!

ElePub is much wiser: it replaces copying by inheriting!
Child objects inherit all attributes from their mother and grandmothers unless they have values of their own overwriting some of the inherited values. Children only own those attributes, in which they really differ from their mother. Everything else is inherited. Therefore, changing one of the mother's attributes will change all of its children unless a particular attribute has been explicitly stored in one child - voluntarily overwriting the value inherited from its mother.

It's so simple and obvious that after a few hours of using this vital feature you will ask yourself why you have wasted so much of your time with copying and re-creating in the past!

By the way: all objects are child objects and most can act as mothers. At the top of the genealogy tree there are some very few Sarah objects, which are the only in the entire system without ancestors and therefore incapable of inheriting.