Object Orientend Programming – The Core Concept
Think of OOP as creating blueprints for real-world entities. Instead of just writing lines of sequential logic, you group data and behavior together into a blueprint (Class) to create individual items (Objects).
4 Pillars of OOP
Inheritance
Children get features/traits from parents, It promotes code reuse and establishes a logical “is-a” relationship between classes.

Polymorphism
This means “many forms.” It allows objects to take on different forms. There are two main types:
– Compile-time polymorphism (Method Overloading) is when a class has multiple methods with the same name but different parameters. The compiler decides which method to call at compile time based on the arguments.
– Runtime polymorphism (Method Overriding) is when a subclass provides a specific implementation for a method already defined in its parent class.

Abstraction
This is the process of hiding complex implementation details while only showing the essential features of an object. It allows you to focus on what an object does, rather than how it does it. This is often achieved using abstract classes and interfaces.

Encapsulation
This is the bundling of data (variables) and the methods that operate on the data into a single unit, or class. It hides the internal implementation details and protects the data from outside access.

Associations
Composition
A Strong “has-a” relationship (life dependency).
In Composition, the parent class creates the child internally inside its constructor. The parent completely owns it.

Aggregation
A weak “has-a” relationship.
In Aggregation, the child object is created somewhere else and passed into the parent class (usually via a constructor parameter or a setter).

Association (Umbrella for above two)
Association is the most generic, baseline concept used to describe a relationship between two classes. It simply means that one object uses or interacts with another object.
Think of Association as the “parent” umbrella term. Both Aggregation and Composition are just specialized, stricter forms of Association.
- vs Composition
- The Difference: In Association, there is zero lifecycle dependency. In Composition, the child’s lifecycle is 100% chained to the parent (House → Rooms).
- In Code: In pure association, the lifecycle of the associated object is managed entirely outside of the class. In composition, the nested object is explicitly instantiated inside the parent class using the
newkeyword, ensuring they die together.
- vs Aggregation
- The Difference: Association has no direction or hierarchy—it’s a two-way street of equals (Doctor ↔ Patient).
- Aggregation adds a directional container hierarchy (Department → Professor).
- In Code: In pure association, objects often just pass through methods as arguments. In aggregation, the container holds a dedicated list or reference variable of the child objects, which were injected from the outside.
- The Difference: Association has no direction or hierarchy—it’s a two-way street of equals (Doctor ↔ Patient).
In a pure Association, two classes are completely peer-to-peer and independent. They have their own distinct lifecycles, and there is no owner. One object simply knows about the other to help it do its job.
- The Code: It is usually represented by a class having a reference to another object as a field, or simply accepting it as a method parameter.
- The Analogy: Doctor and Patient. A Doctor treats many Patients, and a Patient visits many Doctors. They interact, but they don’t own each other. If the doctor retires, the patient doesn’t cease to exist; if the patient leaves, the doctor keeps practicing.

class Doctor {
// Pure Association: Just a reference to an independent object
public void treat(Patient patient) {
patient.heal();
}
}

Leave a Reply