Coordinate vs Subordinate Components – Subordination
In my German classes, I’ve started learning about subordinating conjunctions and as usual, I started thinking about the parallels of this concept in software design. This isn’t intended to be a language lesson but bear with me while we take a quick look at the construction of a sentence. In language, a subordinate clause requires the main clause which it is “subordinate” to. In the example sentence below the subordinate clause is in italic and the main clause in bold:
Nico ist in Deutschland, weil er Probleme mit seinen Eltern hat.
Nico is in Germany because he has problems with his parents.
In this example, it wouldn’t make much to just say “because he has problems with his parents” without any context, that information is dependent on the context provided by the main clause. Here the subordinating conjunction “because” needs the main clause to form a full sentence which makes sense.
Along with subordinating conjunctions there are coordinating conjunctions which join together two independent sentences. For example:
Ich studiere Mathe und ich studiere Biologie.
I study maths and I study biology.
In this example, both sentences make sense by themselves and the coordinating conjunction “and” brings them both together to form a larger sentence. This got me thinking about the words “coordinate” and “subordinate”. With coordination, we have elements of equal importance being brought together but with subordination, we have the notion of dependency and secondary importance. Let’s have a look at their dictionary definitions from Google:
Subordinate
- Adjective: Lower in rank or position, of less or secondary importance.
- Noun: A person under the authority or control of another within an organization.
- Verb: To treat or regard as of lesser importance than something else, make subservient to or dependent on something else.
Coordinate
- Adjective: Equal in rank or importance.
- Noun: Each of a group of numbers used to indicate the position of a point, line, or plane.
- Verb: To bring the different elements of (a complex activity or organization) into a harmonious or efficient relationship.
We can see from the etymology of the words that coordinate has its roots in “ordo / ordinare” (order) and “co” (together), order together / together order, and that subordinate has its roots in sub (below) and ordinare (order), order below / below order. The notion of coordination and subordination got me thinking about the flow of control in applications with and without the dependency inversion principle applied. What does it mean for components in a system to coordinate with each other? What does it mean for them to be subordinate to one another?
In the below examples the dependency inversion principle hasn’t been applied. Each component is responsible for creating its collaborators and because of this they are subordinate to their dependencies. I originally thought that this was the other way around, that the things being instantiated were subordinate to the creator. However, when I thought about it further I realised that it’s the creator who is subordinate to the dependencies it creates as without these concretions it can’t do its job, whereas the concrete dependencies that were created could exist independently elsewhere in the system.
Further, by creating its own dependencies each component chooses which other components to coordinate with. This means choices about coordination are localised to the component itself. If we look at the meaning of subordinate when used as a verb, “make subservient to or dependent on something else”, we see this in components that create their collaborators. The creator is dependent on the services of the collaborator and perhaps sometimes the existence of the collaborator is dependent solely on the existence of the creator.
C# Example:
JS Example:
By the dictionary definition in the above examples, there’s coordination happening. Remember that definition was “to bring the different elements of (a complex activity or organization) into a harmonious or efficient relationship”, different elements are certainly being organized with relationships between them to perform some activity. However, how harmonious or efficient those relationships are will be judged by the system’s rate of change. In this case, they are fine as the rate of change is zero as there is no need for this system to ever change. However, if the rate of change were higher then static binding may become difficult to describe as harmonious or efficient as it could become an impediment to change. So what does this mean? In a system that isn’t static, creating your collaborators introduces a localised subordination relationship which reduces the ability to coordinate the system as a whole.
