OOP Fundamentals
OOP is a programming paradigm based on objects โ data structures containing data (attributes) and code (methods). The term itself dates to the mid-1960s: Alan Kay, developing Smalltalk, later recalled coiningโฆ
OOP is a programming paradigm based on objects โ data structures containing data (attributes) and code (methods). The term itself dates to the mid-1960s: Alan Kay, developing Smalltalk, later recalled coiningโฆ
OOP Fundamentals treats "class" and "object" as two different kinds of thing โ a class is a blueprint, an object is a concrete instance built from it, and that distinction runs underneath every example on this site'sโฆ
Every example on this page uses class-based inheritance โ a subclass extending a class fixed at compile time. That's the dominant model, and the one this page (and most of this site) assumes by default, but it isn't theโฆ
"One interface, many implementations."
Through the early 1990s, three separate notations for describing object-oriented systems were competing for the same job: Grady Booch's, James Rumbaugh's OMT, and Ivar Jacobson's Objectory. When the three joined forcesโฆ
"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem." โ Christopher Alexander 1
"SOLID is not a framework. It's a way of thinking about software design." โ Robert C. Martin
This page lives in the OOP track for a good historical reason, even though the idea outgrows any one paradigm. Alan Kay, who coined "object-oriented", later insisted the name pointed at the wrong thing: "The big idea isโฆ
Languages are ephemeral; paradigms are foundational. Learn only syntax and every new language is a fresh start; learn how memory, execution flow and state change are managed across paradigms and you can pick up a newโฆ
Students arriving from an imperative module often treat objects as magic containers that simply work. This page removes the magic in three layers: what the machine actually does with your objects (the JVM), how to makeโฆ
Students meet ArrayList , HashMap and TreeSet as a menu of options and pick whichever appeared in the last example they read. That framing misses what a collections library actually is: a set of behavioural contractsโฆ
Class diagrams describe a system's static structure โ the classes that will exist and how they relate. They say nothing about where that structure comes from, or how it behaves once it's running. Two other UML diagramโฆ
Students are taught that int and double are the defaults โ and rarely see how those abstractions leak until a critical bug arrives. This case study builds a numerical tower : a hierarchy of number types, inspired byโฆ