OOP: multiple classes

Defining a class as a **specialised version** of another, taking its attributes and methods and adding its own.

Say it aloud. "A SavingsAccount **is an** Account" → inheritance. "A Car **has an** Engine" → composition.

Calls the **parent's** version — usually the constructor, which sets the inherited attributes. Without it those attributes are never set.

A child class **redefining** a parent's method. Its version is used for objects of that class only.

A child depends on the parent's **internals**, not just its interface, so one change to the parent can break every subclass at once.

The **same call** behaving differently depending on the object it is made on — the caller never asks what type it holds.

**Overloading** — resolved at compile time. Overriding is a child replacing a parent's method, resolved at run time.

A type-checking **if-chain**, repeated everywhere the objects are handled — and every copy is a place to forget a type.

**Nothing** — it works with existing loops immediately, so no working code is edited and nothing can break.

No. Inheritance **shares** a method; polymorphism is the same call **resolving differently** per object. Inheritance is usually how it is achieved.

Exposing only the operations a caller needs and **hiding how they are done**.

**Abstraction** decides *what* is exposed (design). **Encapsulation** enforces *how* it is protected (access control).

Its abstract methods have **no bodies**, so an object of it could be asked to run a method that does not exist.

**Abstract class** when children share real behaviour and attributes. **Interface** when unrelated classes must offer the same operations.

One where the caller must know **how** it works to use it correctly — saveToMySQL() rather than save().

Both are has-a. **Composition** owns the part, which dies with the whole. **Aggregation** references a part that exists independently.

Delete the whole. If the part still makes sense it is **aggregation**; if it is meaningless it is **composition**.

The whole **creating** the part inside itself → composition. The part **passed in** → aggregation.

The **filled** diamond ◆. A hollow diamond ◇ means aggregation.

Looser coupling (interface, not internals), parts swappable at run time, and none of the parent's unwanted members.

A **named, reusable solution** to a recurring problem — a description of a structure and why it works, not a library.

Objects **subscribe** to a subject and are notified when it changes. The subject never knows who is listening.

Putting the decision of **which subclass to create** in one place, so concrete class names are not scattered through the code.

Interchangeable algorithms behind one interface, **selected at run time** — replacing an if-chain that chooses behaviour.

It is **global state**: testing becomes hard and the parts of the program that depend on it are hidden.