I am looking for a short but precise definition of Object-Oriented Programming.
A good definition for a concept is:
- Meaningful: it provides information necessary and sufficient to delineate the concept. It must crucially reject what is outside the concept as well as accept what is inside.
- Clear: it relies on well-understood unambiguous words and preexisting concepts, and provides criteria that are objective (as much as can be).
- Informational: it relates a concept at some level of abstraction to its manifestations at a slightly lower level of abstraction. The definition might invoke concepts at the same level as the one being defined, but only if they are simpler than it, and themselves have good definitions that are reasonably well-known. At times, it can be indeed be most enlightening to decompose a concept into simpler independent concepts of which you give the definition, than to give the combined definition without decomposition.
- Consistent (with itself): it does not contradict itself or lead to absurdities if taken seriously.
- Relevant (consistent with common knowledge): it must generally match the lore commonly associated to the concept. A good definition can, at times, disagree with common opinions and intuitions, but not too often (or else it is something else being defined), and not gratuitously (there must be a conceptual payoff to the cost of this disagreement). Now of course, if the common lore contains mutually contradictory "knowledge", then, the definition must make a choice, and reject some of that "knowledge", or contextualize it to a subset of the concept being defined, etc.
- Productive: the definition if truly great can lead to new discoveries that were not possible before the concept was made clear; it can illuminate parts of the conceptual space that were left out by the fog or the set of bad definitions that preceded it.
- Constructive: an truly great definition provides the conceptual bricks and the orientation that will help who understands it actively wrestle with the concept and act on it.
- What someone who understand both the theory, practice and implementation, the how, the why and the what for, did say, or would say.
The following are clear symptoms of a bad definition:
- Mumbo-jumbo: the definition uses buzzwords and ill-defined terms that don't actually enlighten.
- In-joke: the definition uses jargon and slogans from people living inside the concept bubble that instead should be defined for everyone inside and outside.
- Ambiguity: the definition is unclear, doesn't let who uses it distinguish between what the concept covers or doesn't.
- Enumerations: the definition contains haphazard enumerations of manifestations of the concept, instead of a clear criterion for what is or isn't it in. However, enumerations are alright if they are indeed essential to the concept, and in particular, exhaustive.
- Too Long: the definition contains extra words that are not necessary to the meaning, that only add noise or ambiguity.
- Too short: the definition leaves out words that are necessary for the precise understanding of the concept.
- Overshoot: the definition covers extra ground that should not be covered by the concept.
- Undershoot: the definition leaves out ground that should be covered by the concept.
- Appeal to authority: repeated because some pundit said it, even though it's not a good definition.
- Ignorant: could be said by someone who understands part of the topic and might even be an expert at that part, but not by someone who truly understands the theory, practice and implementation.
What should the definition of OOP cover?
- Languages or subsystems of languages that the authors, the public, and experts agree is OOP, whether the languages are popular or unpopular, whether academic, industrial or hobby projects.
- Languages that DO support design patterns and programming idioms and styles associated with OO.
- Languages that had OOP features added, but only after the features were added.
What should the definition of OOP not cover?
- Languages or subsystems of languages that the authors, the public, and experts agree is not OOP.
- Languages that do NOT support design patterns and programming idioms and styles associated with OO.
- Languages that had OOP features added, before the features were added.
What are acceptable edge cases either way?
- When authors, users, experts, etc., disagree with each other about whether something is OO or not.
- When the language or system is so confidential that there is no reliable consensus on whether it is OO, such that the claims of the authors or of rare experts, do not matter.
- When the claim to being OOP is marketing hype from a past decade back when OO was trendy, at which point the claim should be independently confirmed (or rejected) somehow.
- When the claim either way about the language contradicts the support or lack of support for the usual OO design patterns, idioms, styles.
- In general, it should much more likely that some features would be overhyped as "OO" when they are actually not than the opposite of features being denounced as not OO when they actually are. The ability the support common design patterns should tell us.
- Fringe experts who contradict the mainstream should usually be expected to be cranks who are wrong; but sometimes they are the unsung geniuses whose insight is undeservedly ignored. Their line of reasoning, and not their authority (or lack thereof), should be taken into account: does it lead to a better definition, or a worse one?
- It is more important to have a clear story about what you mean than a strict Yes/No answer to every question. Some questions are bad questions and should be rejected.
- It would be slightly surprising if there were absolutely no mistake and no edge case in common opinions or in my own guesses (a happy surprise, but also the opportunity to double-check).
- I would also be pleasantly surprised if a truly great definition already appeared in the literature, but that would be great news indeed, worth citing.
How deep or abstract should the definition be? Shorter is better. But no shorter than necessary. One sentence is best. A few criteria if necessary. Decomposing into simpler concepts that are then defined is good, if the whole remains short, and/or if the simpler concepts are already known and the additional definition is only for precision. If you have to add or change criteria, you should examine whether the new one contradicts old ones, or makes them redundant, or is redundant with them, or can be happily combined, etc. Each criterion in the final version should be simple and necessary. You may make several attempts and refine or correct them. Do not test every attempt exhaustively against each and every success/failure criterion, but try to abstract your appreciation, and use a couple test cases each time; however, once you have a serious contender, do test it better, and once you have a proposed final answer, test it thoroughly.
Scientific rigor:
- You should consult with relevant literature, and at the end include bibtex for the papers you found truly worthwhile, with doi and url where applicable, (use KEY=VALUE without space separation around =). Prefer earlier variants of a cited article, to help establish priority of ideas.
- Webpages may also be cited if they truly bring key ideas not found in contemporary literature.
- Be not satisfied with "the best explanation" already found in literature; they can be great starting points, but try to extract the essence of them.
- If many people reinvent some concept independently, that's a good sign that it's important; often insight may also be found in the subtle differences between very different presentations.
- Researchers, users, implementers, observers, all have their own biases, that may make their "definitions" or explanations good and bad in different ways. So have artists, streamliners, analysts, or visionaries. Hopefully, your definition will satisfy them all, though it may have to be differently explained or qualified to section of the public.
- Each "mostly good" definition that misses out something, each pair of definitions that do not perfectly overlap, is a great opportunity to explore the concept that was missed.
- Much of the existing literature is just bad, or too biased, or partial, confusing whatever subset of the domain (or sometimes, even, disjoint domain) the authors are interested in.
- Even great authors have blindspots, that do not diminish their greatness, and great insights, that do not diminish their failures, and you should keep the good and filter off or otherwise amend the bad.
- Key insight may be found in less-known authors, old or recent.
- The field often fragments into subfields and schools that each have their own insights, but often lack the insights of other schools. The insights should be neither overstated nor ignored.
- It is possible that you would find that OOP actually means multiple different things, maybe related, yet distinct enough to not be unifiable under the same context, at which point you'd give separate definitions for them, under their own names, at worst "Foo OOP" vs "Bar OOP".
- And maybe giving a name for some not-quite-OOP concepts can lead to better definitions of OOP, or to a common generalization of them that is indeed closer to what people mean by OOP.
- “Taxonomy is the death of science” (Whitehead), and giving names for the sake of giving names is bad, but precisely identifying the concepts that simplify understanding and giving them names is also how science works. The taxonomy must be trimmed and revised after the concepts are clearer.
- If this is a hard task that takes a lot of time, I'd rather see your current thoughts and intermediate results as you go, and have you use agents for information-gathering errands. But you should clearly delineate a final conclusion that is concise. While the definition itself should be short, its justification might not be. That's fine. Repeat the short definition at the end.
- If you give up before you are fully satisfied, fine, give me your best shot(s), and tell me what makes you not satisfied yet.
Round 1 Response from ChatGPT 5.5 (high)
I read your criteria as asking for a definition that is short, but still strong enough to reject “objects as just records,” “OOP as just classes,” and “OOP as just encapsulation.”
Proposed definition
Object-oriented programming is programming with objects: runtime entities that own a representation behind a public protocol, so that a call requests an operation from the object(s) and dynamic dispatch selects the implementation without client code inspecting their representation.
A slightly more compact version:
OOP is programming by protocol-bearing objects whose requested operations are selected by dynamic dispatch rather than by clients inspecting representations.
Why this is the best cut
The core is not classes and not inheritance. Simula made classes, objects, inheritance, and virtual procedures historically central, and Smalltalk made message sending the cleanest cultural archetype; but Self is plainly object-oriented while being prototype-based, and Cook explicitly argues that inheritance is neither necessary nor specific to OOP. (Wikipedia)
The core is also not merely bundling data with functions. A module, closure, record of functions, or ADT can do that. Cook’s useful distinction is that ADTs organize abstraction around operations over a hidden representation, while objects organize abstraction around values that export procedural interfaces; in his sharper later formulation, an object should access other objects through public interfaces rather than inspecting their representations.
Kay’s famous formulation emphasizes “messaging,” local retention/protection/hiding of state-process, and late binding. That points in the same direction, but “message passing” alone is too broad: actors, processes, RPC endpoints, and event loops all pass messages. The OOP-specific form is message or method invocation against object protocols, with late/dynamic selection of behavior. (Userpage FU Berlin)
Dynamic dispatch is the productive technical center because it gives interoperable extension: old client code can work with new object implementations through the same protocol. Aldrich makes this explicit by identifying dynamic dispatch as OOP’s key technical characteristic for independently interoperating extensions.
Tests
What the definition deliberately excludes
It excludes “OOP = classes + inheritance,” because that undershoots prototype OO and overstates inheritance. It excludes “OOP = encapsulation,” because ADTs and modules encapsulate. It excludes “OOP = real-world modeling,” because many excellent OO designs model services, protocols, states, strategies, and responsibilities rather than “things.” It excludes “OOP = everything is an object,” because many accepted OO languages have non-object primitives or static functions.
Final definition, repeated
Object-oriented programming is programming with objects: runtime entities that own a representation behind a public protocol, so that a call requests an operation from the object(s) and dynamic dispatch selects the implementation without client code inspecting their representation.
BibTeX for the most worthwhile sources