Definition: Collaborator

I have been coming across the term collaborator in software literature, and I have been using it too in my own writings, but without having seen it defined. I tried searching for its definition, but could not find any. In UML the term collaboration is vaguely described, but not the term collaborator. After asking on Software Engineering Stack Exchange I was pointed 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 use in my own writings.

Here it goes:

A collaborator is a component invoked by another component to do a job.

(And since the context is software, these are, of course, software components.)

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". 

Problems with the original definition

• The original paper was written in the context of Smalltalk, which relied on message-passing, but more generally, collaborators exchange invocations. 
• 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 just filler and it needs to go.
• 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"; however, 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.

Components vs. Interfaces

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.

Availability

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.

Delivery of invocations

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 request-response pairs; 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 requests and responses are:

a) Invocation delivery details, and 

b) System deployment and wiring concerns.

Therefore, they should always be abstracted away, ideally in a completely automatic and transparent way, so that we never have to deal with them in any way whatsoever when writing code. 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

• From an architectural point of view, where any components worth discussing are injectable, collaborator components are never dependencies, because no component depends on any particular implementation of another component. However, the interfaces of the collaborators are dependencies of the components that invoke them, 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 dependencies, because when a component is hard-coded to make use of a certain component, it explicitly depends on that particular concrete implementation.

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

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