Collaborator

A collaborator is an object that another object depends on and talks to in order to perform its function – a dependency it delegates part of a job to. If a ReportService asks a Clock for the time and a Repository for the records, the clock and the repository are its collaborators.

Collaborators generally focus on behavioral interactions rather than ownership and structure. From a design or modeling standpoint, it’s a logical and abstract entity rather than a concretion. Mechanically, this is typically implemented using dependency injection.

This term is used extensively through the Matt Pages as a means of conveying something that is a logical dependency and provides a specific behavior for a unit.

Since the Matt Pages preach only Best Practices™, architecture discussed in any resource will be following SOLID Principles, and as such almost all dependencies should be essential collaborators. This comes for free thanks to having well-defined and focused responsibilities.

How this different from a “dependency”?

The terms are related but not interchangeable.

• A dependency is a structural relationship: one component requires another.
• A collaborator is a behavioral relationship: two components work together to perform a task.

As an example, imaging you have an object like:

classDiagram

class UserService {
  +CreateUser(name)
  -userRepo UserRepository
  -logger Logger
}

class Logger {}
class UserRepository {}

UserService --> UserRepository: Uses for creating users
UserService --> Logger: Uses for logging diagnostics

classDiagram

class UserService {
  +CreateUser(name)
  -userRepo UserRepository
  -logger Logger
}

class Logger {}
class UserRepository {}

UserService --> UserRepository: Uses for creating users
UserService --> Logger: Uses for logging diagnostics

Suppose CreateUser only calls userRepo during the operation, while logger is only used for diagnostics. If discussing the behavior of CreateUser, you might say:

• UserRepository is a collaborator in the user creation use case.
• Logger is a dependency, but not an essential collaborator in the business logic.

References

• Class-responsibility-collaboration card – the “collaboration” in CRC: a class’s collaborators are often dependencies, but with an emphasis is on behavioral interaction rather than ownership.