Inheritance and Polymorphism
A complete explanation of polymorphism requires additional material specifying how behavior varies among related classes.
Try it: Inheritance and Method Lookup
How a subclass inherits from its parent, how Python finds an attribute by walking the instance, then the class's method resolution order up to object, how overriding and super() work, why the same call does different things on different objects (polymorphism), and what isinstance / issubclass check.
How it works
- class Dog(Animal) gives Dog the MRO Dog → Animal → object; Puppy(Dog) gives Puppy → Dog → Animal → object.
- obj.name searches obj.__dict__, then each class of type(obj).__mro__ in order; the first class that defines the name wins, so a subclass method overrides the parent's.
- super().method() starts the search in the class after the one the current method was defined in, e.g. to run the parent's __init__.
- Calling the same method on a list of different objects runs each object's own version (polymorphism).
- isinstance(obj, C) is True when C is in type(obj).__mro__; if no class has the name, Python raises AttributeError.
Default run (63 steps): Ready: Animal, Dog, Cat and Puppy, then the statements you picked. Each attribute is searched along the class's MRO. … Finished. Printed: Rex the dog says Woof / Tom the cat says Meow / Bo the dog says Woof! / True / Puppy / Dog / Animal / object.
Simplified: The lab's own small Python interpreter runs a fixed, hand-written script (you choose the variant and the values, never the code); nothing is executed as real Python. Every script was run in CPython 3.12 with the same inputs and the lab reproduces its output and error messages. Single inheritance only (the lab's MRO code is Python's C3 algorithm, but no class here has two parents).
Loading the simulation…
The Organizing Question
Every program must answer a basic design question: should the code be organized around functions that process data, or around entities that contain data together with the operations performed on that data? Procedure-oriented programming and object-oriented programming answer this question differently. Inheritance and polymorphism belong to the object-oriented programming area, but the source material for this article focuses on the foundation needed to understand that area: the contrast between the two paradigms, the bundling of data and behavior, and the relationship between classes and objects.
Tracing Data and Behavior
One Problem, Two Design Questions
Imagine a program that must work with a set of data. Which design question distinguishes the two programming paradigms?
- 1Procedure-oriented view
Start by asking what sequence of operations is needed. Functions are central, and those functions manipulate data that is kept separate from the logic.
- 2Object-oriented view
Start by asking what entities exist and what each entity can do. Data and the behavior that operates on that data are bundled together in objects.
- 3Growth consideration
For a straightforward small program, procedural code is often simpler to write initially and easier to understand. For a large, complex system, object-oriented programming can scale better.
The key distinction is not that one paradigm is always correct. It is whether the problem naturally decomposes into a sequence of operations or into entities with their own state and behavior.
In procedure-oriented programming, data and logic have separate roles. Functions provide the operations, while data is passed to or handled by those functions. In object-oriented programming, an object combines the data it contains with the behavior that operates on that data. This bundling changes how a programmer thinks about the system: procedural thinking emphasizes steps, while object-oriented thinking emphasizes entities, their state, and their behavior.
Classes and Objects
A class is a template that defines the structure and behavior of objects. An object is a specific instance of a class with actual values.
The class-to-object relationship explains how object-oriented design can describe many similar entities without treating every entity as an unrelated design. The class supplies a shared structure and behavior. Each object is an instance of that class and has actual values. The objects therefore follow the same class template while representing specific instances.
The source material uses Python integers as an example of the class-and-object relationship. When you create a variable of type int, you create an object that is an instance of the int class. The int class defines how integers behave, while each integer object has its own value and follows the same class template.
Inheritance as a Design Relationship
Inheritance is named in this article's topic, but the supplied source material does not define its detailed rules, syntax, or runtime behavior. The source does establish the object-oriented foundation needed before studying it: classes define structure and behavior, objects are instances of classes, and object-oriented programming groups data with the operations on that data. Treat inheritance as a relationship to study on top of this foundation rather than assuming details that are not specified here.
Polymorphism and Method Choice
Polymorphism is also named in the article topic, but the supplied source material does not define its method-selection rules or provide an example of the same operation being used with different object classes. What the source does establish is the setting in which such a topic belongs: object-oriented programming uses objects that bundle data and behavior, and classes define the behavior that objects follow. A complete explanation of polymorphism requires additional material specifying how behavior varies among related classes.
Choosing a Paradigm
| Question | Procedure-oriented programming | Object-oriented programming |
|---|---|---|
| What organizes the design? | Functions that manipulate data | Objects that bundle data and behavior |
| What way of thinking is emphasized? | What steps must be performed? | What entities exist and what can they do? |
| Where does it fit well? | Small to medium programs and straightforward tasks | Large, complex systems and problems naturally decomposed into entities |
| Main trade-off | Often simpler initially | Can add complexity upfront while scaling better for large systems |
The source describes both paradigms as useful; the problem's structure should guide the choice.
Choose procedure-oriented programming when the problem naturally breaks into a sequence of operations and the simplicity of a smaller or straightforward program is valuable. Consider object-oriented programming when the problem naturally breaks into entities with their own state and behavior, especially as the system becomes large or complex. This is a design decision, not a rule that makes one paradigm universally superior.
Common mistake Assuming object-oriented programming is always better.
What it looks likeChoosing objects for every small, straightforward task simply because the program may grow someday.
Why it failsThe source states that procedural code is often simpler initially and works well for small to medium programs.
Do this insteadAsk whether the problem naturally decomposes into entities with their own state and behavior before choosing object-oriented design.
Common mistake Treating a class and an object as the same thing.
What it looks likeCalling a class a specific value.
Why it failsA class is a template, while an object is a specific instance with actual values.
Do this insteadUse the class as the definition of structure and behavior, and use the object for the concrete instance.
Common mistake Thinking the paradigms differ only in naming.
What it looks likeReplacing function names with class names without changing how the problem is organized.
Why it failsThe paradigms organize code around different central ideas: operations and data separately, or entities with bundled data and behavior.
Do this insteadBegin by asking either what steps are needed or what entities exist and what they can do.
Common mistake Inferring detailed inheritance or polymorphism rules from the topic name alone.
What it looks likeAssuming a child class's exact behavior or method-selection rule without a stated language rule.
Why it failsThe supplied source material names these concepts but does not define their detailed mechanics.
Do this insteadUse the class, object, data, and behavior foundations here, then consult a source that specifies inheritance and polymorphism mechanics.
Design Decision Practice
A program is described as a straightforward task that can be expressed as a sequence of operations on data. Which paradigm is the more natural first choice according to the source, and what trade-off should you remember?
Hints
- Look for the paradigm organized around a sequence of operations.
- The source compares initial simplicity with scalability for large, complex systems.
Evaluating the Choice
A problem can be described either as a sequence of operations or as a collection of entities with their own state and behavior. How should the design choice be evaluated?
- 1Identify the natural decomposition
Decide whether the problem is more naturally expressed as operations performed on data or as entities that combine data with behavior.
- 2Consider the program's scale
Procedural programming works well for small to medium programs. Object-oriented programming scales better for large, complex systems.
- 3Weigh the trade-off
Procedural design is often simpler at first. Object-oriented design may introduce more complexity initially but can make a growing system easier to understand, modify, and extend.
Choose the paradigm that matches the problem's natural structure while considering the program's size and complexity.
Key Takeaways
- 1Procedure-oriented programming centers on functions that manipulate data and keeps data separate from logic.
- 2Object-oriented programming bundles data and the behavior that operates on that data into objects.
- 3A class is a template defining structure and behavior; an object is a specific instance with actual values.
- 4Procedural design is often a good fit for straightforward small to medium programs, while object-oriented design can scale better for large, complex systems.
- 5The supplied material establishes the foundation for inheritance and polymorphism but does not specify their detailed mechanics.
At a glance
- Procedure-oriented programming organizes code around functions that manipulate separate data.
- Object-oriented programming organizes code around objects that bundle data and behavior.
- Classes define templates, while objects are specific instances with actual values.
- Choose between paradigms by asking whether the problem is naturally a sequence of operations or a set of entities with their own state and behavior.
- Inheritance and polymorphism require additional rules beyond the foundations provided in this source pack.