JJ van Zon, 2021
Contents
- Introduction
- Relationships Between Classes
- Bidirectional Relationships
- Bidirectional Relationships Between Objects
- Bidirectional Relationship Synchronization
This topic aims to introduce the idea that the build up of classes might be viewed as a model of relationships between classes. A notation for bidirectional relationships is suggested. An attempt is also made to describe how relations between classes might compare to relations between objects.
One object may relate to another object.
But that might not be what the topic of relationships might commonly be about. It might be more about relationships between classes than individual objects.
Relations between classes may determine the configuration of how objects are connected to each other, rather than just loosely tying together arbitrary objects.
A sub-object inside a class could have a class. This might relate these two classes together.
When class might set the class for a sub-object like that, the sub-object might only be an object of that specific class.
Object B might point out a class with a dashed line connected to Related Class B. Otherwise, Object B's connection with the solid line might not be possible.
Here another example: an attempt to depict an object and its class with two more related classes.
The Class might contain two sub-objects, each pointing to another class. The Object might get contents similar to the Class. To 'see' the relationships between classes, it might be an idea to focus on the dashed lines.
The class of a related item might not be set.
Then any type of object might be assigned as a related item. That might not introduce a relationship between classes.
A class may also specify related lists. That might be expressed in a diagram with a nonagon symbol:
A nonagon might be placed inside a class, which could symbolize a class with a list inside of it:
When no class might be assigned to the list, it might imply that the list could contain objects of any class. No relation between classes might be introduced by that.
When a class might be assigned to a list, it may suggest the list might only contain items of this class.
There is also the idea that a list might be assigned multiple classes, which could mean that items of a fixed set of classes could be put in the list.
In that case one related list may create two relationships between classes.
The relationships described so far might be unidirectional: one way only. A unidirectional relationship between one class and another might look like this:
Class A might have a sub-object of Class B. This may create a relationship from Class A to Class B.
Relationships might also be bidirectional: a two-way street. If one class relates to another, then the other class might relate back to the first class again.
In the image above Class B might not seem to have a relationship back to Class A yet. The picture below might add that relationship back to Class A:
In case of a bidirectional relationship if one class gets a sub-object of another class, the other class might also get a sub-object pointing back.
Because the class references back and forth seem so closely related, an addition to the notation is proposed here. The two class lines may be joined together with a relational ring:
The picture above might express a 1 to 1 relationship between Class A and Class B. (The relational ring's being dashed might just be a stylistic choice.)
Other multiplicities might also be used. A multiplicity of n might be expressed with a nonagon:
A nonagon might represent a list of things.
There may be 1 to n relationships between classes. Instead of letting a Class A contain a single item of Class B, it may contain a list of items of Class B:
The picture above aims to express a bidirectional 1 to n relationship between Class A and Class B. In that case one class may have a list of items of another class. The other class might have a single item, that connects back to the first class.
The picture below aims to display a bidirectional n to 1 relationship between Class A and Class B.
There may also be bidirectional n to n relationships, where one class might hold a list of items of another class, and the other class might also hold a list of items, that connects back to the first class. The picture below aims to display a bidirectional n to n relationship between Class A and Class B.
There is an idea where one list might contain items from multiple classes. Class A might have an n to 1 relationship to items of Class B and Class C, of which the picture below aims to express a bidirectional version:
A class may relate to itself. For instance, a person might relate to a parent, which could also be a person. So then a person might be related to a person, which might relate the person class to itself.
A class with a bidirectional relationship to itself could look as follows in a diagram:
Classes and their relationships might define behavior of a system, so it might be relevant to be aware of them, instead of looking at individual objects, tied to other objects. The example below could be a piece of the class-relationship structure of a drawing program. It aims to display the classes Application, Document, Point and Line and the bidirectional relationships between.
The example attempts to display all the classes, relationships, related items and related lists of the class structure. Here might be an attempt to describe with text the classes and relationships that might be drawn out in the picture. A running Application could hold multiple open Documents. So Application could have a 1 to n relationship with the Document class. Viewed in the opposite direction, this could make a Document reference the single Application it might be opened in. A Document might hold a collection of Points and a collection of Lines. That might make Document have a 1 to n relationship with Point and a 1 to n relationship with Line. Inversely, this might make a Point or Line point out one Document it belongs to. Furthermore, a Line could be composed of two Points: Point A and Point B. The idea is that Points could be reused in multiple lines. Perhaps a bit creatively, these became collections inside a Point called As Point A in Lines and As Point B in Lines. It may be a bit non-obvious that it might be a 1 to n relationship, involving lists of lines.
Relationships between classes might set guidelines for how objects could connect to each other. Relationships between objects could be the actual connections between objects.
One idea about bidirectional relationships between objects might be: for each reference to an object, the other object might contain one reference back.
Drawing out the separate counterparts of a relationship between two objects might look like this:
To express the closeness of the relationship between the two objects, a relational ring may be placed around the two lines:
The bidirectional relationships between objects all seem to be 1 to 1. That might be a bit of a bold statement. And it might be just one way of looking at it. But here the idea is entertained that when one object might refer to another, the other one might refer back to the first one.
Bidirectional 1 to n and n to n relationships between classes might result in multiple 1 to 1 relationships between objects.
1 to n:
A multiplicity of n may create a list inside a class. In objects these lists might contain separate items. Any item in the list references an object and that might give the other object one reference back again, in case the relationship is bidirectional.
For n to n relationships it may work similarly:
Sometimes an object might relate to itself. For a bidirectional relationships this might look as follows:
In a bidirectional relationship between classes, one class might relate to another, and the other class might relate back to the first class. But that might not be enough.
An object of one class might refer to an arbitrary object of another class, which then might refer back to an arbitrary object of the first class again, but not necessarily the object we started with.
Two unidirectional relationships might not be synchronized with each other. It might not make the two objects refer to each other. It might just make the two objects refer to an arbitrary object of the other class.
To see to it one object relating to another might make the other object relate back to the first object again, it might be useful for the two counterparts of the relationship to be synchronized.
The tell-tale sign in a diagram, that a bidirectional relationship might be synchronized, could be a relational ring around lines.
When a sub-object's target might then be changed, the other side of the relationship might also be updated.
Relationship synchronization might mean ensuring the integrity between the two counterparts of a relationship. For example, when a Lid might be assigned to a Jar, the Jar might also be assigned to the Lid.
As such, a bidirectional relationship might have three parts:
- One class has a sub-object of another class.
- The other class has a sub-object of the first class.
- The two unidirectional relationships may be synchronized.
The idea might be that that there might be software libraries that have code that make the relationship synchronization work. Circular Language Spec currently only aims to supply a notation for it. There should be freedom of choice how it might be implemented. The notational choices made here, and implementation details might not always resonate with each other. Variations on notations may be possible.