A part either has an ability or it doesn't. Abilities have boolean values. The default is false for all abilities. The following basic abilities are in all nodes:
- Companion
- Container
- ContainerAssistant
- Core
- Hidden
- Service
- Virtual
Abilities are not the same as properties. They are at a higher level of abstraction. A property describes an actual data value, such as weight, height, color, name or age. An ability is whether an entity can do something (or be used for something) or not. Some properties can be abilities, such as is exportable, is configurable, etc.
Parts never know about how they are used is assembling systems. They only know what travels in and out of themselves. For example that's why we can use a part as a service in one case or not a service in another case.
Abilities are all designed with the most common case as false, which is always the default. For example we use "Hidden" instead of "Visible" because most parts are not Hidden.
Companion
A container may have one leaf part that's psychologically associated with the container. An example is a registry. In the visual System Tree companions are shown as with their containers instead of being a child. This helps conceptual understanding of the intent of system design.
Container
A unique type of core part is a container. It holds other container or leaf parts. All other types of parts are leaf parts. A container part requires the other core parts to run. Thus the core parts form the "container" portion of a system. We do not call this "Cell" to allow other types of containers, such as organs.
ContainerAssistant
Container assistant parts are replicated to create subcontainers. This property is more exact than Core and not Container, because some core parts aren't container assistants.
Core
Parts are divided into two groups - core and domain. Core parts are required for a System Tree to run. They are domain neutral, and are normally hidden. Domain parts are the ones supplied by the system builder, have the domain functionality, and form the bulk of a system. The use of core parts by domain parts should be minimized and fascaded to preserve core encapsulation.
Hidden
Most parts are visible in the visual System Tree tool and to "get all parts in a container" calls, etc. But the core parts (except for container) are hidden, because that would clutter up things visually, and expose them to possible misuse by non-core parts. This also helps preserve core encapsulation. The designer can also make some domain parts hidden too.
This ability can be used to control the behavior of classes like "PartReader" to hide sensitive parts.
Service
Parts can collaborate with other parts indirectly with messages, or directly by getting a part and casting it to an interface. The former preserves loose coupling, the latter allows faster and simpler access.
The Service ability applies to parts used directly. Any part can be used directly, but the Service ability allows findPart(String partName) to first check the container the call was made in, and if the partName is not found and upward search is made for Service parts. The search continues until the partName is found and is a Service, or the root is reached. Thus Service parts are inherited.
This allows a part to be a "part service". Some parts play a part service role by sitting near the upper region of a System Tree and serving the needs of many parts below by being inheritable. This is the Service Architecture Pattern, though that pattern is not limited to trees.
We also have a "message service" that uses upward searching in aimilar manner. We recommend the use of "message service" instead of "part service" for most use, because of looser coupling.
An example of the use of Service is core service parts. This allows cores that don't use messages, gives greater speed, and allows part sharing of stateless parts by many containers for efficiency. One purpose of this property is so the designer can declare that a part NOT be used as a service, which can improve cell encapsulation. Another advantage is automatic management of service parts by a service registry or such.
The cool thing is you can have a part in a container being used directly. Then one day you get a brainstorm and figure out how to make it reusable in many containers. All you have to do is move the part up in the System Tree and set its Service ability to true using Container DK. The parts who were using it before with findPart(partName) will still get the same part. Neither the client parts or the service part know what happened. This is Ultra High Reuse at its finest! :-)
Virtual
Parts may be normal or "virtual". Normally all parts are defined in Container DK. But virtual parts are not defined by Container DK. This allows more dynamic system behavior, less DK, and lighter system weight. An example of virtual parts is core parts in subcells below the root.
Virtual means a part definition is not in the usual place, and so the part appeared out of nowhere.