Traditionally, object oriented modeling proceeds "top down" in that classes/interfaces are defined first and then instances (i.e. "objects") are created. Essence Precedes Existence. The objects consist of the class-defined attribute set, the whole class-defined attribute set, and nothing but the class-defined attribute set!
In Existential Programming, the developer can define "bottom up" classes/interfaces where, after the fact, attributes can be chosen from existing ones, or new "computed" attributes can be added. Existence Precedes Essence. This is very similar to the database concept of "view" where some subset of columns can be dealt with as if they were their own table/entity. These views can also add "computed" or "joined" columns thus supporting the philosophy that there is a fine (or non-existent) line between "behavior" and "data". They are all just properties, and it is inside the black box that the details exist of what was required to get or set that property (using Java-speak).
A difference between this object view idea and normal interfaces is that the interface declaring a method has to be defined before the class that implements it is defined, which in turn is before an object (based on that class definition) is created. With a view, an object could be "cast" to some defined-after-object-creation interface, as long as that object had the methods/properties that the view expected. Otherwise, potentially a cast-exception could be thrown (or, it could just let you work with any methods that *did* match). Of course, with Existential Programming, all "interfaces" and "classes" are the same as "views". There is no single "real" version of an object/entity with other versions just "views". This is different from database views where down deep there IS a "real" table (or several if the view was really a "join"). With Existential Programming's strategy of using EAV structure for persistence, all entity definitions / classes / interfaces are "views".
This sort of thing is done with dynamic languages like JavaScript and is called "duck typing". This name reflects 2 puns simultaneously:
External Abstraction ®☺
A related idea I've had is that of the "external abstraction" where, instead of merely views, whole hierarchies of super-classes, subclasses, and interfaces are defined after the fact. ["Internal" abstractions would be those normal OO abstractions where the super-classes and interfaces supported by an object were those that were defined when the object instance was created (i.e. its essence).]
The point of "external" abstractions is that someone "external" (i.e. other than the ontology creator and object instantiator) can decide (after an object has been created) that some aspect of the object is overly specific to one point of view and needs to support other points of view. For example, the "name" attribute of "person" classes is often broken into first name, middle name, last name which is very culturally biased. So, support needs to be added for other cultures where "last name" is not synonymous with "family name", and there is no "Christian name", and not everyone has three names. Is Dances with Wolves' middle name "with"?
Normally, if one were refactoring that class hierarchy to better handle names, one would convert the 3 string fields representing the name into a reference to a new Name interface and define classes that implement various permutations of name. The interface could have methods like getFamilyName() which determined the value based on the particular cultural variant name class instantiated. This is all nice when one can do this beforehand such that is it all compiled and ready for the code to use before the person object is instantiated. With External Abstraction, the developer can do this refactoring and apply it to an entity that has already been created and exists as an object or persisted to some data store. By adding in a newly created " mixin" interface/class to the preexisting object, the 3 name fields can be reinterpreted and mapped to other ontologies supporting other cultures.
In Existential Programming, the developer can define "bottom up" classes/interfaces where, after the fact, attributes can be chosen from existing ones, or new "computed" attributes can be added. Existence Precedes Essence. This is very similar to the database concept of "view" where some subset of columns can be dealt with as if they were their own table/entity. These views can also add "computed" or "joined" columns thus supporting the philosophy that there is a fine (or non-existent) line between "behavior" and "data". They are all just properties, and it is inside the black box that the details exist of what was required to get or set that property (using Java-speak).
A difference between this object view idea and normal interfaces is that the interface declaring a method has to be defined before the class that implements it is defined, which in turn is before an object (based on that class definition) is created. With a view, an object could be "cast" to some defined-after-object-creation interface, as long as that object had the methods/properties that the view expected. Otherwise, potentially a cast-exception could be thrown (or, it could just let you work with any methods that *did* match). Of course, with Existential Programming, all "interfaces" and "classes" are the same as "views". There is no single "real" version of an object/entity with other versions just "views". This is different from database views where down deep there IS a "real" table (or several if the view was really a "join"). With Existential Programming's strategy of using EAV structure for persistence, all entity definitions / classes / interfaces are "views".
This sort of thing is done with dynamic languages like JavaScript and is called "duck typing". This name reflects 2 puns simultaneously:
- "quacks-like-a-duck" typing (vs strong or weak typing)
- duct taping (which is what all weakly typed programming is in the opinion of many)
External Abstraction ®☺
A related idea I've had is that of the "external abstraction" where, instead of merely views, whole hierarchies of super-classes, subclasses, and interfaces are defined after the fact. ["Internal" abstractions would be those normal OO abstractions where the super-classes and interfaces supported by an object were those that were defined when the object instance was created (i.e. its essence).]
The point of "external" abstractions is that someone "external" (i.e. other than the ontology creator and object instantiator) can decide (after an object has been created) that some aspect of the object is overly specific to one point of view and needs to support other points of view. For example, the "name" attribute of "person" classes is often broken into first name, middle name, last name which is very culturally biased. So, support needs to be added for other cultures where "last name" is not synonymous with "family name", and there is no "Christian name", and not everyone has three names. Is Dances with Wolves' middle name "with"?
Normally, if one were refactoring that class hierarchy to better handle names, one would convert the 3 string fields representing the name into a reference to a new Name interface and define classes that implement various permutations of name. The interface could have methods like getFamilyName() which determined the value based on the particular cultural variant name class instantiated. This is all nice when one can do this beforehand such that is it all compiled and ready for the code to use before the person object is instantiated. With External Abstraction, the developer can do this refactoring and apply it to an entity that has already been created and exists as an object or persisted to some data store. By adding in a newly created " mixin" interface/class to the preexisting object, the 3 name fields can be reinterpreted and mapped to other ontologies supporting other cultures.
Posts
No comments:
Post a Comment