Ken Webb 2010-05-13T23:59:04Z
In the current Java implementation of the Xholon framework, all objects in an application inherit from the Xholon class which implements the IXholon interface. IXholon combines a number of different concerns.
I would like to give objects a choice of which concern(s), if any, they implement. I need to work on a version of Xholon where the IXholon interface is broken down into a number of smaller interfaces, each with its own completely independent orthogonal concern.
The following is a first attempt to discover a set of core orthogonal concerns.
- An object can be identified, such as by using an ID, a UID, a name, a role name, an XPath expression, or some other feature(s) that uniquely distinguishes it from other objects instances.
- This is currently implemented by Xholon.id and associated IXholon methods.
- An object can have programming language attributes (Java primitives (int, double, boolean, ...), instances of java.lang classes (Integer, Double, Boolean, ...), instances of java.util collection classes (List, Map, ...)).
- An object can be part of a composite structure hierarchy (a tree). It can have a parent, siblings, and children.
- This is currently implemented by Xholon.parentNode Xholon.firstChild Xholon.nextSibling and associated IXholon methods.
- An object can be part of a network by cross-connecting to other objects, that are not immediate parents, children, or siblings.
- An object can be client of services. Services allow for an unrestricted number of non-core concerns.
- An object can socialize with other objects by sending and receiving messages. Those objects may be parents, children, siblings, cross-connections, or whatever. Objects that socialize may of may not be part of the same composite structure hierarchy, if any.
- An object can be part of an application framework.
- An object can be associated with a class. This may be a Xholon class, and/or a programming language (Java) class.
- This is currently implemented by Xholon.xhc and associated IXholon methods, and by java.lang.Object.
- An object can be managed by a human and/or by software.
- This is currently implemented by Xholon action and actionList.
- An object can be associated with a mechanism/namespace/domain. (this may be a Xholon class concern).
- Each concern should have a small number of core methods that would be part of the Java interface. Non-core and helper methods could be implemented in a separate static class, or in a concern-specific service, or in some other way.
- An RDBMS also has orthogonal concerns, which roughly map onto some of the Xholon orthogonal concerns. Connectable is related to foreign key references, Classifiable to tables, Attribute concern to columns, Identifiable to primary keys.
- Some of the XPath axes have to do with orthogonal concerns. Composable is related to child/descendant/parent/ancestor/following-sibling/preceding-sibling, Attribute concern to attribute, Namespace concern to namespace, Identifiable to self. Connectable is what XPath is all about.
- The w3 DOM-2 Node interface has some of the same concerns. Composable is related to parentNode/childNodes/firstChild/lastChild/previousSibling/nextSibling, Classifiable to nodeType, Application concern to ownerDocument, Attribute concern to attributes, Namespace concern to namespaceURI/prefix/localName, Identifiable to nodeName.
- UML has many of the same concerns.
return to main page