Association
In the real world, nothing exists in isolation.
- A doctor has patients.
- A driver has a car.
- A student enrolls in courses.
These connections define how different entities interact and collaborate.
When we design software using Object-Oriented Programming (OOP), our goal is to model this real world where objects communicate and work together to achieve meaningful outcomes.
So, how do we represent these connections between our objects?
In this chapter, we will explore the most fundamental and common of these relationships: Association.
1. What is Association?
Association represents a relationship between two classes where one object uses, communicates with, or references another.
This relationship models the idea:
“One object need to know about the existence of another object to perform its responsibilities”
If Class A must interact with Class B to fulfill its purpose, then Class A is associated with Class B.
Real-World Analogy
Think of a Student and a Teacher.
- A student has-a teacher who teaches them.
- A teacher teaches multiple students.
However:
- A student can still exist without a teacher.
- A teacher can still exist without any specific student.
This is a real-world association:
- The relationship exists.
- But neither party owns the other.
- Their lifecycles are independent.
Key Characteristics of Association:
- Association reflects a "has-a" or "uses-a" relationship.
- Associated objects are loosely coupled and can exist independently of one another.
- The association can be unidirectional or bidirectional, and can follow different multiplicity patterns (1-to-1, 1-to-many, etc.).
2. UML Representation
In UML class diagrams, association is represented by a solid line between two classes:
Basic Syntax
- Solid line (—): Represents an association between classes.
- Arrowhead (→): Indicates directionality (who knows whom).
- No arrowhead: Implies a bidirectional association.
Multiplicity defines how many instances of one class can be associated with another. It is written near the class ends in UML diagrams.
Symbol | Meaning | Example Scenario |
|---|---|---|
| Exactly one | Each |
| Zero or one (optional) | An |
| Many (zero or more) | A |
| At least one | Each |
3. Types of Association
Associations between classes can vary depending on how objects are connected and in which direction information flows.
In Object-Oriented Design, associations are primarily defined by two key properties:
- Directionality — Who knows about whom?
- Multiplicity — How many objects are connected?
3.1 Based on Direction (Directionality)
Directionality determines which class holds a reference to the other and whether communication is one-way or two-way.
a. Unidirectional Association
In a unidirectional association, only one class is aware of or holds a reference to the other class.
Example: An Order object uses a PaymentGateway to process transactions, but the PaymentGateway doesn't keep track of any orders.
b. Bidirectional Association
In a bidirectional association, both classes are aware of each other. Each class holds a reference to the other, enabling two-way communication.
Example: A Team has a list of Developers, and each Developer knows which Team they are part of.
3.2 Based on Multiplicity
Multiplicity defines how many instances of one class can be associated with instances of another class. It describes the quantity and nature of the connections.
a. One-to-One Association
Each object of one class is linked to exactly one object of the other class.
Example: Each User has exactly one Profile, and each Profile belongs to one User.
b. One-to-Many Association
One object of a class is linked to multiple objects of another class.
Example: Each Project can have many Issues (e.g., bug reports, feature requests), but each Issue belongs to one Project.
c. Many-to-Many Association
Multiple objects from one class are associated with multiple objects from another class.
Example: A User can be a member of multiple Groups (e.g., WhatsApp groups, Slack channels), and a Group can have multiple Users.
In this chapter, we explored association - the foundational relationship that allows objects to interact while maintaining their independence.
But in many real-world systems, relationships are not always this loose. Sometimes, one object acts as a container or owner of others, creating a more structured hierarchy.
This brings us to the next level of relationship modeling in OOP: Aggregation.
Lets explore that in the next chapter.