2023-01-16

Definition: Collaborator

Collaboration, by michael.gr, based on original 'Gear' by Lluisa Iborra (https://thenounproject.com/icon/gear-1031260/) and 'hands making a circle' by Oleksandr Panasovskyi (https://thenounproject.com/icon/hands-making-a-circle-4289633/) from the Noun Project.

A collaborator is a component invoked by other components to do a job.

I noticed that I have been coming across this term quite often in software literature, and I have been using it a lot, but without ever having seen it defined. So, I tried searching for its definition, but could not find any. After asking on softwareengineering.stackexchange.com, someone pointed me to what is in almost all certainty the original definition, but it turns out that it is very old, and slightly problematic, so I thought I should provide a modern definition here, at the very least for referring to it when I use the term in my own writings.

Origin of the term

(Useful pre-reading: About these papers)

Collaborators were introduced as a concept in a paper by Kent Beck and Ward Cunningham in 1989 (See http://c2.com/doc/oopsla89/paper.html) and defined as "objects which will send or be sent messages in the course of satisfying responsibilities". 

The "in the course of satisfying responsibilities" part seems to convey no information, despite the fact that it comprises about half of the definition; it is probably filler to make the definition sound better.

The paper was written in the context of Smalltalk, which relied on message-passing, but more generally, collaborators exchange invocations. 

The paper allowed a collaborator to be either "a service with little regard or even awareness of its client" or a "near-equal" in a "symmetric relation", but nowadays we tend to put emphasis on loose coupling, so collaborators are generally services: a component has knowledge of collaborators that it employs, but a collaborator has no specific knowledge of components that it is employed by.

The UML specification contains a definition of the term Collaboration, for example in UML 2.5.1

Notes

Depending on the scope of the discussion, the term collaborator may mean two things of different nature:

  • When discussing a component and its collaborators, the term collaborator usually refers to an interface, because a component is supposed to be invoking interfaces, not actual implementations.
  • When discussing a system and the components in it, the term collaborator refers to an actual component implementing one or more interfaces, because components is what systems consist of.
When there is a need to differentiate between the two, the terms Collaborator Interface and Collaborator Component can be used.

The term does not imply any particular mechanism for making a collaborator component available to a component that wants to use it. The collaborator might be hard-coded, might be supplied as a parameter to an interface method call, might be injected, etc. If the mechanism by which a collaborator is being made available is unclear, and if it matters, then it should be explicitly stated. However, in software architecture we are usually discussing collaborators that may appear in architectural diagrams, and these tend to be injectable. Collaborators that are hard-coded or supplied as parameters tend to be small-scale implementation details that generally do not appear in architectural diagrams.

The term does not imply any particular mechanism for placing invocations; one collaborator might be invokable via programmatic interface method calls, while another might be invokable via message-passing, and yet another might be invokable via REST-over-HTTP; if the mechanism of placing invocations is unclear, and if it matters, then it should be explicitly stated. Having said that, I should add that in most cases it should not matter, because writing software using any invocation mechanism other than programmatic interface method calls is misguided; things like message-passing or REST-over-HTTP are a) invocation delivery details, and b) system deployment and wiring concerns, so they should always be abstracted away, ideally in a completely automatic and transparent way, so that we never have to deal with them. Thus, when I speak of invocations between collaborators, and unless I explicitly state otherwise, I mean programmatic interface method calls, with the provision that some automatic and transparent conversion between such calls and some other invocation delivery mechanism might be taking place under the hood if necessary.

Similarities and differences from dependencies

  • Collaborator interfaces are always dependencies, because a component needs to import an interface in order to make invocations to it, otherwise it will not compile. (Assuming we are using a real programming language, meaning a strongly typed programming language.)
  • Collaborator components that are available via hard-coding are of course also dependencies, because when a component is hard-coded to make use of a certain collaborator component, it explicitly depends on that particular concrete implementation.
  • Collaborator components that are available not via hard-coding, but instead via injection or parameter-passing, are never dependencies; when an instance of a collaborator is injected or passed to a component, the component depends on the interface of that collaborator, but not on any particular concrete implementation of that interface.

---------------------

Reference: softwareengineering.stackexchange.com - Definition of "collaborators" (of an object) in Software Design?

No comments:

Post a Comment