{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.tr.object-oriented-programming","code":"thing-q79872","url":"https://ver.cy/models/thing/q79872/","name":"object-oriented programming","alternateNames":["prototype-based programming","object-oriented programming in PHP","Python Programming/Classes","actor-based programming","class-based programming","concurrent object-oriented programming"],"kind":"thing","status":"published","version":"0.1.0-research.1","language":"en","classifiers":{"family":"Thing Registry","category":"Activities and processes","entryKind":"thing","plane":"ACT","domain":["ACT.ACT"],"industry":[],"navPath":"","tags":[],"facets":{}},"whatItIs":"Object-oriented programming is a programming paradigm that structures a program as interacting objects associating state with behaviour exposed through methods or messages, commonly using encapsulation and class-based or prototype-based mechanisms to organise and reuse behaviour, with late-bound polymorphic dispatch supported by many implementations but not required by every object-oriented design.","purpose":"Enable an AI agent to recognise an object-oriented programming approach, assess how its objects preserve contracts and collaborate, and determine which implementation or design changes are justified.","scope":{"in":["Evidence that a program organises behaviour around objects and their interactions","Object identity, state ownership, encapsulation and invariants","Class-based or prototype-based object construction and behaviour reuse","Method lookup, dynamic dispatch, polymorphism and behavioural contracts","Object collaboration, composition, inheritance and substitutability","Assessment and modification of an object-oriented design within its implementation context"],"out":["Complete programming-language syntax, compiler implementation and language specification","General software requirements, product capabilities and business-domain definitions","Database schemas, persistence engines and object-relational mapping configuration","Deployment architecture, infrastructure operation and service topology","General project management, developer competency and team organisation","Functional, procedural or logic programming except where needed to identify boundaries or mixed approaches"],"boundaries":[]},"distinguishingFeatures":["Determine whether objects receive operations through a defined interface and supply associated behaviour; records merely passed among free functions are insufficient evidence by themselves.","Determine whether object boundaries organise responsibilities and state access in actual code; the presence of class declarations alone does not establish an object-oriented design.","Identify whether operations can select behaviour through a receiver's class, prototype or other object mechanism; distinguish this from branches over externally interpreted type tags without assuming every object-oriented design requires dynamic dispatch.","Determine whether classes act as object definitions, namespaces or data containers; distinguish object-oriented use from procedural code packaged inside classes.","For an entity-component design, determine whether behaviour resides in collaborating objects or primarily in systems processing passive components; record mixed cases rather than classifying by terminology."],"structure":{"bundles":[{"id":"paradigm-and-object-mechanisms","name":"Paradigm and object mechanisms","description":"Establishes where object-oriented programming is being assessed and how objects are represented.","layers":[{"id":"application-boundary","name":"Application boundary","description":"Defines the unit of assessment and the evidence for its programming approach.","findings":[{"id":"object-oriented-organisation","name":"Object-oriented organisation","description":"Records how responsibilities and interactions are organised around objects within the selected boundary.","questions":[{"text":"Which codebase, subsystem or design proposal is assessed, and which responsibilities are assigned to objects?","id":"object-oriented-organisation-q01","kind":"boundary"},{"text":"Which code examples or design records demonstrate object-centred behaviour rather than classes used only as namespaces or records?","id":"object-oriented-organisation-q02","kind":"provenance"}]}]},{"id":"object-definition-mechanisms","name":"Object definition mechanisms","description":"Identifies how instances obtain state and behaviour.","findings":[{"id":"classes-prototypes-and-instance-structure","name":"Classes, prototypes and instance structure","description":"Records the mechanisms used to define, instantiate and alter objects without treating classes as mandatory.","questions":[{"text":"Do objects obtain behaviour from classes, prototypes, per-instance members or another documented mechanism?","id":"classes-prototypes-and-instance-structure-q01","kind":"definition"},{"text":"Can an object's members or behaviour providers change after creation, and what language or runtime evidence establishes this?","id":"classes-prototypes-and-instance-structure-q02","kind":"provenance"}]}]}]},{"id":"identity-state-and-encapsulation","name":"Identity, state and encapsulation","description":"Captures what makes an object the same object and how its state remains valid.","layers":[{"id":"identity-and-aliasing","name":"Identity and aliasing","description":"Examines equality, copying and shared references.","findings":[{"id":"identity-equality-and-copy-contracts","name":"Identity, equality and copy contracts","description":"Records when references denote the same object and when distinct objects count as equal.","questions":[{"text":"How are object identity and value equality distinguished, including any equality and hashing contract?","id":"identity-equality-and-copy-contracts-q01","kind":"definition"},{"text":"When an object is copied or replaced, which identities and references remain shared, and which caller observations must remain equivalent?","id":"identity-equality-and-copy-contracts-q02","kind":"action"}]}]},{"id":"state-access-and-invariants","name":"State access and invariants","description":"Identifies protected conditions and paths that can bypass their enforcement.","findings":[{"id":"invariant-enforcement-boundary","name":"Invariant enforcement boundary","description":"Records valid object states, permitted mutation paths and the limits of encapsulation.","questions":[{"text":"Which conditions must hold at observable operation boundaries, and which constructors or methods establish and preserve them?","id":"invariant-enforcement-boundary-q01","kind":"definition"},{"text":"Can callers bypass those methods through public fields, mutable values returned by accessors, aliases or reflective access?","id":"invariant-enforcement-boundary-q02","kind":"boundary"}]}]}]},{"id":"interfaces-dispatch-and-substitution","name":"Interfaces, dispatch and substitution","description":"Connects callable object contracts with implementation selection and replacement.","layers":[{"id":"operation-resolution","name":"Operation resolution","description":"Captures how a requested operation resolves to executable behaviour.","findings":[{"id":"method-lookup-and-dispatch","name":"Method lookup and dispatch","description":"Records binding, overriding and lookup rules used by the assessed implementation.","questions":[{"text":"For a representative operation, which receiver, declared types, runtime types or prototype links determine the selected implementation?","id":"method-lookup-and-dispatch-q01","kind":"definition"},{"text":"Which language rules and code evidence distinguish overloading, overriding, member hiding and delegation where they occur?","id":"method-lookup-and-dispatch-q02","kind":"provenance"}]}]},{"id":"behavioural-compatibility","name":"Behavioural compatibility","description":"Assesses polymorphic replacement against observable obligations.","findings":[{"id":"substitution-obligations","name":"Substitution obligations","description":"Records preconditions, outcomes, failures and state effects that implementations must preserve.","questions":[{"text":"What inputs, results, exceptions and state changes may callers rely on through the shared interface?","id":"substitution-obligations-q01","kind":"definition"},{"text":"What evidence shows that a proposed replacement accepts the required inputs and preserves those guarantees?","id":"substitution-obligations-q02","kind":"action"}]}]}]},{"id":"responsibilities-and-object-collaboration","name":"Responsibilities and object collaboration","description":"Describes how objects divide work and combine behaviour.","layers":[{"id":"responsibility-allocation","name":"Responsibility allocation","description":"Locates decisions, state and operations across collaborating objects.","findings":[{"id":"collaboration-and-knowledge-boundaries","name":"Collaboration and knowledge boundaries","description":"Records which objects perform a task and how much each knows about others' internals.","questions":[{"text":"For a representative task, which object owns each decision and which collaborators does it invoke?","id":"collaboration-and-knowledge-boundaries-q01","kind":"definition"},{"text":"Which interactions depend on collaborators' internal representation or long navigation chains, and what changes would those dependencies propagate?","id":"collaboration-and-knowledge-boundaries-q02","kind":"boundary"}]}]},{"id":"reuse-and-extension","name":"Reuse and extension","description":"Separates behaviour sharing from interface compatibility.","findings":[{"id":"inheritance-composition-and-delegation","name":"Inheritance, composition and delegation","description":"Records the intent and consequences of each mechanism used to reuse or extend behaviour.","questions":[{"text":"Which relationships provide implementation reuse, which promise substitution, and which forward work to contained or referenced objects?","id":"inheritance-composition-and-delegation-q01","kind":"definition"},{"text":"For a proposed extension, what caller contracts, override dependencies and ownership assumptions determine whether inheritance, composition or delegation is appropriate?","id":"inheritance-composition-and-delegation-q02","kind":"action"}]}]}]},{"id":"object-lifecycle-and-change-evidence","name":"Object lifecycle and change evidence","description":"Records when objects are usable and what evidence permits changes to their behaviour or structure.","layers":[{"id":"construction-and-retirement","name":"Construction and retirement","description":"Captures object readiness, valid transitions and responsibility for resources.","findings":[{"id":"lifecycle-validity","name":"Lifecycle validity","description":"Records how objects become valid, which operations are legal in each state and how obligations end.","questions":[{"text":"When does an object become valid for use, and can partially initialised state escape through callbacks, registration or overridable constructor calls?","id":"lifecycle-validity-q01","kind":"boundary"},{"text":"Which operations are permitted after each lifecycle transition, and who must release any resources the object owns?","id":"lifecycle-validity-q02","kind":"action"}]}]},{"id":"behaviour-preserving-change","name":"Behaviour-preserving change","description":"Defines the observations and checks needed to assess object-oriented refactoring.","findings":[{"id":"refactoring-evidence","name":"Refactoring evidence","description":"Records whether a proposed structural change preserves required contracts, identity effects and interactions.","questions":[{"text":"Which observable results, state transitions, identity relationships and collaborator effects must a proposed refactoring preserve?","id":"refactoring-evidence-q01","kind":"boundary"},{"text":"Which contract checks and representative interaction tests support the change, and which affected behaviours remain unchecked?","id":"refactoring-evidence-q02","kind":"action"}]}]}]},{"id":"evidence-and-external-alignment","name":"Evidence and external alignment","description":"What the world already says about this thing, gathered so the model can be checked against it.","layers":[{"id":"reported-evidence","name":"Reported evidence","description":"Findings from the breadth pass, kept separate from the structural claims.","findings":[{"id":"evidence-kinds","name":"Kinds and varieties","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these kinds and varieties hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-kinds-q01","kind":"provenance"}]},{"id":"evidence-identifiers","name":"Identifiers and schemes","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these identifiers and schemes hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-identifiers-q01","kind":"provenance"}]},{"id":"evidence-standards-and-regulation","name":"Standards and regulation","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these standards and regulation hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-standards-and-regulation-q01","kind":"provenance"}]},{"id":"evidence-real-world-use","name":"Real-world use","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these real-world use hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-real-world-use-q01","kind":"provenance"}]},{"id":"evidence-measurements","name":"Typical measurements","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these typical measurements hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-measurements-q01","kind":"provenance"}]},{"id":"evidence-failure-modes-and-hazards","name":"Failure modes and hazards","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these failure modes and hazards hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-failure-modes-and-hazards-q01","kind":"provenance"}]},{"id":"evidence-regional-variation","name":"Regional variation","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these regional variation hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-regional-variation-q01","kind":"provenance"}]},{"id":"evidence-neighbours","name":"Neighbouring kinds and how to tell them apart","description":"Reported by the breadth pass; each item needs checking against its source before it becomes normative.","questions":[{"text":"Which of these neighbouring kinds and how to tell them apart hold for the sense of object-oriented programming this model covers, and on what evidence?","id":"evidence-neighbours-q01","kind":"provenance"}]}]}]}]},"agentConduct":{"may":["Explain object-oriented concepts such as encapsulation, inheritance and polymorphism with examples.","Design and refactor object-oriented code in projects it is authorized to change, keeping tests passing."],"mustNot":["Present one language's object model as the only correct form of the paradigm.","Break encapsulation to reach private data it is not meant to access.","Push large refactors to shared code without review or tests.","Copy licensed code or class libraries against their licence terms."],"requiresHuman":["Changing public interfaces that other teams or customers depend on."]},"ethics":{"considerations":["Design choices shape how easy software is to maintain and secure.","Paradigm debates can exclude learners when framed as dogma."],"affectedParties":["Developers","Users of the software","Students"]},"owners":{"steward":"Nobody owns the paradigm; authors and owners of code answer for their programs.","roles":[],"masterSystems":[]},"relations":[{"target":"Q223335","type":"parent","note":"registry parent class"}],"interaction":{"identity":{"applicability":"required","items":["Vercy registry: vr.tr.object-oriented-programming","Wikidata: Q79872 (https://www.wikidata.org/wiki/Q79872)"]},"properties":{"applicability":"not-applicable","items":["Assessment boundary: language capability | codebase | subsystem | library | design proposal","Object organisation mechanism: class-based | prototype-based | hybrid | other documented mechanism | unresolved","Identity semantics: reference identity | value equality | both with explicit distinction | context-dependent | unresolved","State exposure: hidden behind operations | exposed read-only | directly mutable | mixed | unresolved","Dispatch mechanism: Record supported and used mechanisms, such as static binding, receiver-based dynamic dispatch, multiple dispatch or prototype delegation.","Behavioural contract evidence: unspecified | documented | partially checked | checked within a stated boundary | known violation","Reuse and substitution relationships: composition | delegation | implementation inheritance | declared subtyping | structural compatibility; identify endpoints and evidence","Inheritance depth: Maximum number of inheritance edges from a root to a assessed type, with treatment of multiple inheritance stated","Mutable-state sharing: Record which objects share access to mutable state and which operations may modify it."]},"recognition":{"applicability":"not-applicable","items":[]},"capabilities":{"applicability":"required","items":["Classify a bounded implementation's object-oriented mechanisms using code and language evidence.","Trace an operation from its receiver through method lookup, dispatch and delegated calls.","Identify exposed state, invariant violations and unsafe assumptions about object identity.","Assess whether a proposed subtype preserves the behavioural expectations of its callers.","Propose changes to responsibility allocation, interfaces, composition or inheritance and specify the evidence needed before applying them.","Construct checks for object contracts, lifecycle transitions and polymorphic behaviour."]},"hazards":{"applicability":"required","items":["Poorly controlled shared mutable state can produce inconsistent behaviour and defects that are difficult to reproduce.","Deep inheritance hierarchies and tight coupling can make local changes break distant parts of a system.","Objects that fail to enforce their invariants can allow invalid data to propagate through an application.","Incorrect assumptions about overridden methods can violate caller expectations and undermine reliability or security."]},"interfaces":{"applicability":"required","items":["ISO/IEC 19505-1 and ISO/IEC 19505-2, issued jointly by the International Organization for Standardization and the International Electrotechnical Commission, standardize the Unified Modeling Language used to describe object-oriented software designs."]},"context":{"applicability":"required","items":["Object-oriented programming is used to organize software around objects that combine state with operations on that state.","It is commonly encountered in application development, simulations and reusable software frameworks.","It supports designs in which components collaborate through defined interfaces and can provide different implementations of shared behaviour."]}},"sources":[{"title":"The Early History of Smalltalk","url":"https://dl.acm.org/doi/10.1145/155360.155364","note":"Kay's specialist account of OOP as messaging, local retention and protection of state, and extreme late binding, against later class-and-inheritance reductions."},{"title":"Dimensions of Object-Based Language Design","url":"https://dl.acm.org/doi/10.1145/38765.38823","note":"The still-used split between object-based languages (objects) and object-oriented languages (objects plus inheritance), and other design dimensions."},{"title":"The Quarks of Object-Oriented Development","url":"https://dl.acm.org/doi/10.1145/1113034.1113040","note":"Empirical practitioner consensus that encapsulation, inheritance, and polymorphism are the properties people actually treat as definitional."},{"title":"A Metrics Suite for Object Oriented Design","url":"https://doi.org/10.1109/32.295895","note":"The CK quantities (WMC, DIT, NOC, CBO, RFC, LCOM) still used to measure OO designs."},{"title":"On Understanding Types, Data Abstraction, and Polymorphism","url":"https://dl.acm.org/doi/10.1145/6041.6042","note":"How inclusion polymorphism and data abstraction underpin typed OOP, and how that differs from ADTs alone."},{"title":"Unified Modeling Language (UML) specification","url":"https://www.omg.org/spec/UML/","note":"The dominant industrial notation for class, object, and related structure used to describe OO systems."},{"title":"Wikidata item Q79872: object-oriented programming","url":"https://www.wikidata.org/wiki/Q79872","note":"identity and sense of the item"},{"title":"Wikipedia: Object-oriented programming","url":"https://en.wikipedia.org/wiki/Object-oriented_programming","note":"general description of the item"}],"openQuestions":["Which existing Vercy world models already own programming paradigms, object contracts or software design, and should this registry entry link to one of them?","What operational recognition threshold should Vercy use for object-oriented programming in mixed codebases, especially where objects lack dynamic dispatch or contain little behaviour?","Should the primary assessment unit be the programming approach itself or a bounded application of it, and how should those levels relate?","Which language-specific extensions are needed for multiple dispatch, traits, mixins, prototype mutation and metaprogramming?","When should concurrency, persistence identity and distributed object lifecycles extend this model rather than remain in neighbouring models?"],"resources":{"spec":"/models/things/publications/thing-q79872/spec.json"},"provenance":{"origin":"thing registry research (pass 2)","builtFrom":["models/things/publications/thing-q79872/spec.json"],"providers":["Codex","Grok"],"researchStatus":"unreviewed","generatedAt":"2026-09-07T14:10:53Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"not-applicable","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"_gate":"Published through the thing publication gate 1.0 on 2026-10-07T12:16:34+00:00: completeness 1.00; sense: Wikidata description; 4 live sources; review by codex: pass","interaction.properties":"Plane ACT: no invented physical properties.","interaction.recognition":"A programming paradigm is an abstract approach whose use must be assessed from software structure and behaviour rather than visual appearance."},"score":1.0}}