Classes and Inheritance
Classes can be stand-alone Classes without any association to other Classes. However, most Classes build upon other previously defined Classes and are organized in a hierarchy, or tree, structure. In this case the new Classes can pull from, or inherit, the definition of the previously defined Class. The Sub-Class automatically inherits all features that are configured for a Super-Class.
This concept of inheritance is central to the core of GroverDB. In most Object-Oriented technologies, inheritance only applies to Attributes and Methods. In GroverDB, inheritance applies to every feature:
- Attributes (Called Data Fields)
- Object States (Called Statuses)
- Connections (Object-to-Object Connections)
- Data Policies (rules to identify data exceptions)
- Class Filter elements
- Relational access (SQL)
Inheritance also applies when the user browses Objects. By default, selecting a Super-Class includes selecting all the Objects in all Sub-Classes.
A Class can be set as an Abstract Class, which means it's only there for inheritance purposes and cannot itself be directly used by Objects. Setting a Class as Abstract is useful for a Top-Level Class that has multiple Sub-Classes and every Object should be in a Sub-Class.
There are certain (uncommon) situations when a Class needs to inherit from more that one Super-Class. GroverDB fully supports multiple inheritance. Any Class can inherit from multiple other Classes. The classic example is a pet dog that needs to inherit from both the Pet Class and the Canine Class. By defining the Pet-Dog Class with both the Pet Super-Class and the Canine Super-Class, any Object in the Pet-Dog Class automatically includes all the features defined for both Pets and Canines.
Note: There are some Class properties or behaviors that could potentially conflict when a Class inherits from multiple Super-Classes. For these Object Class properties, the Sub-Class inherits that property as true if it is true for any Super-Class.