Object-Oriented Programming.

Encapsulation, abstraction, inheritance and polymorphism are the four pillars.

• Encapsulation keeps an object's data with the code that changes it, reachable only through the object's methods.
• Abstraction shows what an object does and hides how it does it.
• Inheritance lets one class build on another.
• Polymorphism lets one piece of code work with several types.

The four overlap. Encapsulation and abstraction are two views of the same boundary. One hides state, the other hides steps. Inheritance is only one route to polymorphism, and often not the best.

Treat them as tools, not goals. Applying all four to every class produces deep hierarchies and wrappers that add nothing. The payoff is that a change lands in one file instead of twenty, and a new case plugs in without touching old code.

Encapsulation means an object owns its data, and outside code reaches that data only through methods the object controls. Fields stay private, and the class decides which changes are legal.

Hiding state gives you three things:

• You enforce invariants in one place, so an account refuses a withdrawal that goes below zero and no caller can skip that check.
• You swap the internal representation, a list for a map, without touching callers.
• When a balance is wrong, only one class can have changed it, so only that class needs checking.

The cost is extra code. A plain data holder passed between two functions gains nothing from private fields and pass-through accessors. The extra layer only makes the code longer to read.

Abstraction is deciding what to leave out. You name an operation by its intent and hide the steps behind that name. A caller writes save(order) and never learns whether that is a SQL insert, a file write or an HTTP call.

Four techniques do this. Interfaces state a contract with no implementation. Abstract classes fix a shape and leave gaps for subclasses. Ordinary methods give one name to a block of steps. Access modifiers back all of this up by keeping the internals out of reach.

A wrong abstraction costs more than none. If the contract you picked does not match how callers use the thing, every caller writes a workaround. Flags and special cases follow. Duplicated code is easier to fix later than a bad abstraction everyone depends on.

Inheritance lets one class take another's fields and behaviour as a starting point, then add to them or replace parts. It gives code reuse and a subtype relationship, so a dog can be passed anywhere an animal is expected. The second matters more.

Textbooks name the shapes by how the arrows point:

• Single: one class extends one parent.
• Multilevel: a chain, where a child is also a parent.
• Hierarchical: several classes extend the same parent.
• Multiple: one class extends more than one parent, which most languages allow for interfaces but not classes.

The split worth remembering is implementation inheritance versus interface inheritance. Taking a parent's code ties you to its internals, so its next change can break you. Taking only its contract does not.

Polymorphism means code written against one name works with many types, and the right version runs automatically. A loop calling shape.area() gets the circle's formula for circles and the square's for squares.

Languages support several flavours:

• Subtype polymorphism: a subclass or implementation supplies its own version, and the object picks at runtime.
• Ad-hoc polymorphism: one name, several parameter lists, resolved when the code is compiled. Operator overloading is the same idea.
• Parametric polymorphism: generics, where one List<T> works for every element type.
• Duck typing: in dynamic languages, any object with the right method fits.

The gain is that adding a type does not mean editing existing branches, so old code stays untouched. The cost is indirection. Reading a call site no longer tells you which method actually runs.

Composition means one object holds another and asks it to do work. Inheritance means one class is a specialised kind of another and receives its members automatically. A car has an engine, and an electric car is a car.

Three differences matter in practice.

• Inheritance is fixed when the code is written, while a composed part can be swapped at runtime.
• A subclass can see protected members, while a holder sees only the public members.
• A subclass inherits the whole parent interface, wanted or not.

Both reuse code, but only inheritance also declares substitutability. That promise is what lets a subclass be passed where the parent is expected, and it is the part you cannot take back later. If all you want is reuse, composition makes no such promise, so the held part stays easy to change.

An interface states a contract and nothing else. An abstract class states a contract plus part of the implementation. It can hold fields, constructors and finished methods that subclasses share.

• A class can implement many interfaces but extend only one abstract class. That makes an interface cheap to add to a type that already has a parent.
• An abstract class can carry state and enforce an order of steps.
• Classes from unrelated hierarchies can implement the same interface.

Some languages now let interfaces carry default method bodies. State and constructors still belong to classes. The choice comes down to whether subclasses share code, or only share a capability that callers depend on.

SOLID is an acronym for five design rules that keep code easy to change, test and reuse.

• Single responsibility: a class should have one reason to change.
• Open/closed: you can add behaviour without editing code that works.
• Liskov substitution: a subtype must work wherever its base type does.
• Interface segregation: small contracts beat one fat contract.
• Dependency inversion: high-level code should depend on abstractions, not concrete classes.

Teams bother because each letter names a pain they have felt.

• Shotgun edits across five files for one change.
• An if chain that grows with every feature.
• A subclass that throws from an inherited method.
• Stubs full of empty methods.
• Logic that cannot run without a real database.

Applied blindly, SOLID produces a class per line of logic, which is its own mess.

SOLID makes code easier to maintain by keeping each change local, and easier to test by letting each class run on its own.

For maintainability, single responsibility gives each class one clear purpose, so a change is predictable and lands in one place. Dependency inversion puts abstractions between modules, which reduces the ripple effects of a change. Open/closed lets you extend behaviour without modifying code that works. Liskov substitution lets you swap one component for another without breaking callers.

For testability, dependency inversion and interface segregation mean a class depends on small interfaces. A test replaces those with mocks or stubs. Single responsibility keeps classes small and focused, so each one is easier to unit test.