Encapsulation, abstraction, inheritance and polymorphism are the four, and each buys something different. Encapsulation keeps an object's data and the code that changes it together, behind a guarded door. 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.

These are not four independent features. 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 one.

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

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. The private keyword is the mechanism; the discipline is the point.

Hiding state buys 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. And when a balance is wrong, the suspect list is one class, not the whole codebase.

The cost is ceremony. Not every type needs a wall around it. A plain data holder passed between two functions gains nothing from private fields and pass-through accessors, and the extra layer just 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.

The techniques are ordinary. 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 at all. If the contract you picked does not match how callers use the thing, every caller writes a workaround. Flags and escape hatches 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 two things at once: code reuse, and a subtype relationship, so a dog can be passed anywhere an animal is expected. The second is the part that matters.

Textbooks name the shapes by how the arrows point:

• Single: one class extends one parent.
• Multilevel: a chain, where a child is itself a parent to something else.
• 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. Every subclass is also a standing promise to keep behaving like the parent, which is easy to make and hard to keep.

Code written against one name can work with many different 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. The calling code never branches on type.

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, with no declared type.

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, and a debugger or a stack trace becomes the only honest answer.

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; an electric car is a car.

Three differences bite 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 surface. 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 asks for less and gives back more room to change.

An interface and an abstract class can both ship working code today. The real dividing lines are state, constructors and the single-inheritance slot.

Java 8 added default and static methods to interfaces. C# 8 added default interface implementations.

interface Greeter {
    String name();
    default String greet() { return "Hi, " + name(); }
}

Interfaces cannot hold instance fields (per-object data) or define constructors. An abstract class holds both, plus protected helpers 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.

The choice comes down to whether subclasses genuinely share code, or only share a capability that callers depend on.

Five design rules, one per letter, all aimed at code that people keep changing.

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

Teams bother because each letter names a specific pain they have already felt. Shotgun edits across five files for one change. An if chain that grows with every new feature. A subclass that throws from a method it inherited. Stubs full of empty methods. Logic that cannot run without a real database. Applied blindly, though, SOLID produces a class per line of logic, which is its own mess.

SOLID is an acronym representing five fundamental design principles for object-oriented programming that promote clean, maintainable, and extensible code:

• S - Single Responsibility Principle: A class should have only one reason to change
• O - Open/Closed Principle: Software entities should be open for extension but closed for modification
• L - Liskov Substitution Principle: Objects should be replaceable with instances of their subtypes
• I - Interface Segregation Principle: Clients should not depend on interfaces they don't use
• D - Dependency Inversion Principle: Depend on abstractions, not concretions

Benefits of following SOLID principles:

• Maintainability: Changes are localized and predictable
• Flexibility: Easy to extend and modify existing functionality
• Testability: Components can be tested in isolation
• Reusability: Well-designed components can be reused across different contexts
• Reduced coupling: Components are loosely connected and independently changeable
• Code clarity: Intent and structure are clearer and easier to understand