Recent time with Clique Space(TM) has dragged me into the dependency nightmare that is Java generics; a nightmare from which I might be awakening.
Clique Space code comes in two halves. The chassis is the basic Clique Space data structure definitions and implementation of functionality in relation to the sending and receiving of transmitters while the top half is the body of the specific implementation of a Clique Space aware device.
The halves are separated by a set of parameterised types that make the cute acronym disclosed in the title of this blog entry. The specific device implementation's body "clips on" to the generic chassis. Hence, the chassis defines these generic parameters, and the body completes their implementation. The terms used in the acronym are as follows:
- CL - The basic Clique structure and mechanisms contained therein.
- I - The Identity structure and mechanisms contained therein.
- P - The basic Participant structure and mechanisms contained therein.
- O - A more specific Participant structure relating to Owner Participants of subscriber Cliques and involvements.
- N - A more specific Participant structure relating to non-Owner Participants of subscriber Cliques and involvements.
Hence, these extra two types (O and N) are used to ensure that an Owner Participant is returned where an Owner Particpant is expected and a non-Owner Participant is likewise returned when expected. This type of discrimination is important in cases where structures derived from the basic Clique (the synapse, the service, and the viscera... possibly others as yet uncontemplated) are being manipulated. These specific Clique structures have extra functionality because this extra functionality helps a Clique space do the things I intend it to do.
A thing of beauty.