Object-Oriented Programming practice questions

Use a property decorator on a class method

Why wrong: Applying @property to a method intended to be shared treats it as an instance-level data descriptor: accessing it on the class yields the property object itself, not a value, and accessing it on an instance invokes the getter with that instance, so it cannot expose a single class-wide value. It also offers no write protection for the underlying class attribute, which can still be reassigned directly via the class name. Thus it neither creates true shared state nor enforces read-only access.

Define a public class attribute and document it as read-only

Why wrong: Merely documenting a public class attribute as read-only does not add any enforcement mechanism in Python; a subsequent `ClassName.attr = value` statement will silently change it for the whole class, and `instance.attr = value` creates an instance shadow that masks the class value only for that object. Documentation cannot block assignment, so the guarantee of read-only sharing rests entirely on developer discipline, not language behavior.

Define an instance attribute inside __init__

Why wrong: An attribute assigned in `__init__` via `self.attribute = ...` lives in the instance's `__dict__`, not in the class namespace, so every new instance creates its own independent copy. Changing it on one object has no effect on other instances or on the class itself, and there is no single shared value to access from the class. This directly contradicts the requirement for a shared class attribute.

Encapsulation

Why wrong: Encapsulation is not the correct answer because it focuses on bundling data with the methods that operate on it and restricting direct access to an object's internal state, typically via private attributes and public accessors. While encapsulation protects data integrity and reduces coupling, it does not provide any mechanism for different types to exhibit different behavior through a shared interface. Handling different types primarily requires behavioral variation, which encapsulation alone cannot deliver.

Inheritance

Why wrong: Inheritance is not the correct answer because it establishes a parent-child 'is-a' relationship, enabling code reuse and propagation of attributes/methods from a base class to subclasses. However, simply inheriting methods does not automatically produce different behavior for each type; a subclass may inherit a method unchanged, resulting in identical behavior. Despite common misconceptions, inheritance only enables behavior variation when subclasses override inherited methods — and that overriding, along with runtime dispatch, is the essence of polymorphism, not inheritance itself.

Abstraction

Why wrong: Abstraction is not the correct answer because it is about simplifying complexity by exposing only relevant high-level operations and hiding implementation details, often through abstract classes or interfaces. While abstraction can define a common contract for different types (e.g., an abstract method signature), it does not decide how each concrete type implements that contract. Abstraction lays the groundwork, but the actual runtime selection of a specific type's implementation is performed by polymorphism, making it the direct solution.

Because the attribute is defined as a class attribute, not instance attribute

Why wrong: Name mangling rewrites every identifier of the form __private that appears in a class body, regardless of whether it is assigned in __init__ or directly in the class statement. Defining the attribute as a class attribute does not change the substitution: in MyClass it becomes _MyClass__private, while the subclass's reference to __private becomes _MySubClass__private. The AttributeError is caused by the nonexistence of that subclass-mangled name, not by the attribute being a class-level rather than an instance-level storage.

Because the subclass overrides the method that uses the attribute

Why wrong: If the subclass overrides a method that uses __private, the overriding method is compiled in the subclass namespace, so its self.__private access is rewritten to self._MySubClass__private. Overriding the method does not create that attribute, nor does it affect the original base-class method's own mangled reference, which remains _MyClass__private and is inherited and usable inside the base-class method. Thus the override is irrelevant to the AttributeError; the problem is purely the textual name transformation that occurs in the subclass.

Because the attribute is private and not inherited

Why wrong: Python has no truly private members; double underscores only trigger name mangling, not inheritance blocking. The attribute _MyClass__private is an ordinary attribute of the instance and is inherited by subclass objects, so it is accessible from outside or from base-class code as _MyClass__private. It is not inherited as __private, because the subclass textually mangles that spelling to its own class prefix, making the private marker a source-code renaming rather than an access-control boundary.

3

Why wrong: The value 3 would only be visible if you inspected car1's own attribute after the assignment, because car1 now has an instance attribute that shadows the class attribute for that specific object. However, car2 is a distinct instance with no 'wheels' key in its own namespace, so it cannot see car1's shadowing entry. Python's lookup for car2 continues past the instance and finds the class attribute, which is still 4, making 3 an incorrect answer.

AttributeError

Why wrong: AttributeError would only be raised if neither the instance's __dict__ nor any class in the MRO contained a 'wheels' attribute. Here the Car class explicitly defines wheels = 4 at class creation time, so that attribute exists and is accessible to every instance that does not shadow it. Since car2 does not shadow it, accessing car2.wheels resolves successfully to 4—no missing-attribute exception can occur.

None

Why wrong: None is not a fallback in Python's attribute lookup mechanism; if an attribute is not found, the interpreter raises AttributeError rather than silently returning None. Car2 has no instance attribute named wheels, so the lookup proceeds to the class and retrieves the class attribute's value, which is the integer 4. The only way this option would even be plausible is if Car explicitly set wheels = None, but the class definition sets it to 4.

The assignment is silently ignored

Why wrong: The assignment is silently ignored is wrong because Python never silently ignores an attribute assignment on a class that defines __slots__. When you try to set 'z', which is not listed in __slots__, the instance has no __dict__ to store the new attribute, so the assignment cannot be skipped or no-oped; instead, Python's attribute assignment machinery raises an AttributeError. A silent ignore would mean the value is discarded without feedback, but the language explicitly refuses the operation to prevent accidental or unintended dynamic attributes.

Python issues a warning and adds the attribute

Why wrong: Python issues a warning and adds the attribute is wrong because the behavior is not a warning plus accommodation. Under __slots__, the class intentionally omits a __dict__ for its instances, so there is no place to store an undeclared attribute like 'z'. Rather than warn and then store it in a fallback dictionary (which does not exist), Python immediately raises AttributeError at assignment time. Warnings are used for deprecation or resource issues, not for this; this is a hard runtime error.

The attribute 'z' is added dynamically

Why wrong: The attribute 'z' is added dynamically is wrong because the very purpose of __slots__ is to prevent dynamic attribute creation and to allocate exactly the named slots as instance descriptors. Since the instance lacks a __dict__, there is no mechanism for adding new attributes at runtime. Every attribute access or assignment goes through the class-defined slot descriptors, and any name outside the declared slots triggers an AttributeError, so 'z' is never added to the instance.

self.work()

Why wrong: self.work() performs a normal attribute lookup on the self instance, which means the method resolution starts from the class of self — in this scenario, Manager. Since Manager.work() is the method currently executing, calling self.work() inside that method will simply dispatch to the same overridden method again, creating an infinite recursive loop. This is not a delegation to the parent at all; it is a dynamic dispatch that honors the subclass override, so it can never reach Employee.work().

None

Why wrong: The method m references self.a, which is an instance attribute assigned in B.__init__. Since that constructor explicitly sets a to 10, the attribute is never None; Python's attribute lookup finds the integer 10 instead of a default None. None would only appear if the attribute were initialized to None or never assigned and a class-level None existed.

AttributeError

Why wrong: AttributeError is raised only when Python cannot find the requested attribute on the instance or its class hierarchy. Here, before any call to m, B.__init__ runs and creates self.a = 10 on the instance, so the attribute lookup succeeds. If B.__init__ omitted the assignment and A.__init__ did not run, only then would m raise AttributeError.

0

Why wrong: The value 0 is not involved in this code path: B.__init__ assigns the literal 10 to self.a, and no subsequent operation decrements or reassigns the attribute. Unless m explicitly used getattr(self, 'a', 0), there is no mechanism that would produce a fallback default of 0, so the output cannot be 0.

Define borrow as a static method and override in subclasses

Why wrong: Declaring borrow as a static method is wrong because a @staticmethod receives neither self nor cls, so it cannot inspect or modify the borrowing book's instance state, such as its availability, due date, or borrower. Because a static method is merely a function attached to the class namespace, redefining it in a subclass only shadows the name rather than providing true instance-level polymorphic behavior. A borrow operation is inherently stateful and instance-specific, so a static method is structurally unable to implement the required logic.

Define borrow as a class method and override in subclasses

Why wrong: A class method receives cls instead of self, meaning any borrow implementation can access class-level attributes but not the attributes of the particular book being borrowed. Overriding a @classmethod in subclasses dispatches behavior based on the class, not the instance, so it is best suited for alternate constructors or factory helpers, not for an operation whose result depends on the state of an individual item. This fails the design requirement for per-instance behavior and is fundamentally a different mechanism from overriding an instance method.

Define borrow with pass and let subclasses override

Why wrong: Using pass in the base borrow method leaves a default implementation that does nothing and returns None, so an unoverridden subclass call would complete successfully while corrupting the library's invariants—no item is actually borrowed. Since Python has no compiler-enforced override checking, this mistake would go undetected until a user realizes nothing changed. This is the opposite of fail-fast behavior: pass hides a broken design, whereas NotImplementedError surfaces the problem immediately when the method is invoked.

Python always calls the method from the last base class

Why wrong: Python does not use a simplistic 'last base class wins' rule; it uses C3 linearization, which produces a monotonic method resolution order that preserves both local precedence order and constraints from the entire inheritance graph. For example, in class C(A, B), if both A and B define foo, C.foo resolves to A.foo because A is listed first, not last. The actual MRO can intermix classes in a sequence that is neither purely first-to-last nor last-to-first, especially in diamond hierarchies, making this option incorrect.

The 'foo' method in class B is defined after class A's 'foo' in the same file

Why wrong: The physical order of method definitions in a source file has no effect on method resolution; Python compiles the entire module before execution and builds the MRO at class creation time solely from the base-class tuple in the class statement. Even if B.foo appears textually after A.foo, it is the inheritance order — not the order of def blocks — that determines which attribute is found first during attribute lookup. File-level ordering is irrelevant to C3 linearization and attribute resolution.

Python uses depth-first, left-to-right resolution

Why wrong: Python's MRO is not depth-first left-to-right; that was the behavior in older Python 2 versions and was replaced by C3 linearization starting in Python 2.3. C3 fixes the inconsistency and duplicate-lookup problems of depth-first traversal in diamond inheritance (e.g., class D(B, C) with a common base A). It ensures a monotonic order where a subclass always appears before its superclasses and every class appears exactly once, which a naive depth-first approach cannot guarantee.

AttributeError: 'Derived' object has no attribute 'get_x'

Why wrong: This option is wrong because get_x is inherited from Base. In Python, instance methods are looked up on the class of the object and its parent classes through the MRO, so a Derived object can call get_x exactly as if it were defined directly in Derived. There is no reason for an AttributeError; the method exists in Base and is fully accessible from Derived.

10

Why wrong: This option would only be correct if Base.__init__ had run and set self._x to 10. However, Derived.__init__ overrides Base.__init__ and does not call super().__init__(), so the base class initializer is never executed. The only assignment to _x is the one in Derived.__init__, which sets it to 20, making the returned value 20, not 10.

AttributeError: 'Derived' object has no attribute '_x'

Why wrong: This option is wrong because the _x attribute is created in Derived.__init__ before get_x is ever called. When __init__ executes self._x = 20, Python stores _x in the instance's __dict__, so later attribute lookup for _x succeeds. There is no AttributeError because the instance clearly possesses the attribute, and the get_x method simply reads that existing attribute.

Declare 'self.balance' as a class variable

Why wrong: Merely declaring balance as a class variable—via an assignment inside the class body—makes it a public attribute on the class, so any code can read or write it as ClassName.balance or instance.balance. Python does not distinguish between 'public' and 'private' class variables; without name mangling or a property, there is no mechanism to prevent direct access. Moreover, if instances also assign self.balance, that creates a per-instance attribute, but that too remains publicly accessible, so the requirement to ensure privacy is not met.

Declare 'self.balance' and provide a getter method

Why wrong: This approach provides a getter, but the underlying attribute is still called balance with no leading underscores and no name mangling, so callers can access and mutate it directly without ever invoking the getter. A getter is only useful when the attribute itself is hidden or at least non-writable by convention; here, the getter is redundant because the public attribute is already readable and writable. Since the developer specifically wants to ensure (not just suggest) privacy, relying on discipline to use the getter is insufficient.

Declare 'self._balance' and provide a getter method

Why wrong: Using self._balance marks the attribute as 'internal' by a widely followed naming convention, but Python's runtime does not enforce or conceal it. Direct access from outside is still successful: other code can read and assign _balance unless they explicitly choose to respect the underscore. The getter adds no real protection because the single-underscore prefix only signals intent to other programmers, not to the interpreter, so the attribute is not actually private.

'Car started Vehicle started'

Why wrong: This output would be produced only if Car's start() override explicitly called super().start() after printing 'Car started'. The provided override makes no super call, so Python executes only the derived class implementation. Consequently, the base class message is never emitted, making this combined output impossible.

'Vehicle started'

Why wrong: This output would appear if Python used static dispatch based on a variable's declared type, or if Car did not override start(). However, Car does override the method, and Python resolves methods dynamically using the actual runtime type of the object. The instance is a Car, so its own start() is invoked and the Vehicle version is shadowed and never run.

AttributeError

Why wrong: AttributeError occurs when an attribute or method does not exist anywhere in the object's class hierarchy. Here, Car inherits from Vehicle, which defines start(), and Car also provides its own override, so the method is definitely present. The call to instance.start() is completely valid, and no such exception is raised.

Define a new __init__ in Dog that does not call super

Why wrong: Defining __init__ in Dog without calling super().__init__() means Python will treat Dog's __init__ as a complete override of the inherited one. As a result, the Animal constructor's body never executes, so self.name is never assigned; any attempt to read dog.name will raise AttributeError (or the attribute will be missing). This breaks the implicit contract that a subclass initializer must cooperate with its parent, even if Dog adds its own parameters.

Dog will automatically inherit the __init__ method

Why wrong: Merely relying on automatic inheritance is not enough: Dog will indeed inherit Animal.__init__ through normal attribute lookup, but that inherited method still expects a name argument exactly as Animal required. If client code tries to instantiate Dog() without passing name, Python raises TypeError: __init__() missing 1 required positional argument: 'name'. Additionally, "automatic inheritance" does nothing to let a Dog-specific __init__ coexist with the parent's; you'd be locked to the parent's initialization logic and cannot add Dog-only fields.

Use a decorator to initialize

Why wrong: There is no built-in or idiomatic decorator whose purpose is to initialize or chain __init__ methods. Decorators like @classmethod, @staticmethod, or @property are intended for other behavior, and using a custom class decorator that wraps __init__ would be a nonstandard, obscure workaround at best. A decorator cannot by itself solve the constructor-chaining problem cleanly, because the correct solution is to explicitly call super().__init__ from within Dog.__init__.

To access class variables without creating an instance

Why wrong: Accessing class variables without an instance is specifically the job of a @classmethod, which receives the class itself as an implicit cls parameter and can therefore read or modify class-level attributes. A @staticmethod, by contrast, receives neither cls nor self, so it cannot reach class variables unless you explicitly reference the class by name (e.g., MyClass.CLASS_VAR). Thus, while a staticmethod can technically read class variables with explicit qualification, this option misidentifies the defining purpose of a staticmethod.

To allow the method to be overridden in subclasses

Why wrong: The ability to be overridden in subclasses is a general property of all methods in Python inheritance, not a purpose unique to staticmethod. In fact, using a staticmethod for overriding is often awkward because the method does not receive cls or self, so the overriding method cannot access subclass-specific state unless it is passed explicitly. The Pythonic way to design methods for polymorphic override is to use a regular instance method (or a classmethod when class-level customization is needed), so this option confuses an incidental consequence with the intended role of staticmethod.

To enforce that the method cannot be called from an instance

Why wrong: A staticmethod does not restrict callers to the class level; it simply ignores the instance when called. Accessing it through an instance, as in obj.static_method(), does not bind the instance as an argument—Python looks up the attribute on the class and calls the underlying function with only the arguments you provide. The method therefore works unchanged from either a class or an instance, but the ability to call it on an instance means the claimed 'enforcement' simply does not exist.

D, B, A, C, object

Why wrong: This order is what a naive depth-first, left-to-right traversal might produce, but C3 linearization does not allow it. In the merge step, after D and B are emitted, A cannot be taken because A appears in the tail of C's linearization [C, A, object]; the head C must be emitted first. Placing A before C also violates monotonicity, since C's own MRO [C, A, object] would not be a subsequence of [D, B, A, C, object], making attribute lookup inconsistent with C's declared inheritance.

D, B, C, A

Why wrong: This list is incomplete because every Python class ultimately inherits from object, and object must be the final entry in any MRO. C3 linearization always ends with object, as the merge process consumes all base-class tails down to the root. Omitting object would mean there is no terminal class for attribute lookup, so the MRO cannot be considered valid even if the relative order of D, B, C, and A is correct.

D, B, A, object, C

Why wrong: Placing object before C is impossible in a valid MRO because object is the ultimate superclass and must always appear after all of D's base classes. Since C is an immediate base of D, C must be emitted before object; otherwise C's own linearization [C, A, object] cannot be preserved as a subsequence. This order would cause attribute lookup to find nothing in C after object has been searched, breaking the inheritance contract.

Define __init__ that raises NotImplementedError

Why wrong: Raising NotImplementedError inside __init__ is a reliable way to make a class non-instantiable. Every successful call to the class constructor implicitly invokes __init__, so throwing an exception at that point halts instance creation. Subclasses must override __init__ (typically to define their own state) before they can be instantiated. This pattern is concise and works in all Python versions.

Use a naming convention like _BaseClass

Why wrong: A naming convention such as _BaseClass is purely advisory; it communicates intent to human readers but has no runtime effect. Python does not enforce the leading underscore rule, so code can still call _BaseClass() and receive an instance. Tools like linters may warn, but they do not block creation. Thus it is not a mechanism for preventing instantiation.

Define __new__ to return None

Why wrong: Overriding __new__ to return None technically makes the class call return None, but this does not prevent the constructor from running; rather, it subverts Python's object-creation protocol. When __new__ returns None, Python skips __init__ and silently delivers a None object, forcing the caller to handle a missing instance, which often leads to AttributeError. Returning None does not raise a clear error and breaks the expected contract that a constructed object is an instance of the class, making it an unreliable and confusing approach.

obj.attr = 5 on an instance

Why wrong: Assignment to obj.attr = 5 targets an existing instance object, not the class object. Python writes this binding into that instance's __dict__, so only that one object sees attr unless another instance has its own assignment. The class remains untouched, which means this operation can neither define a new class attribute nor serve as a valid way to define a class.

class MyClass: def method(self): pass

Why wrong: The class body 'class MyClass: def method(self): pass' does produce a class, but the assignment it makes binds a function object to the name method in the class namespace. That function is accessed as an instance method through the descriptor protocol, and it is a behavior rather than a data attribute. Because the question asks for a class-attribute definition, this method-defining class body is not a valid answer.

class MyClass: def __init__(self): self.attr = 5

Why wrong: Although this is a valid class definition, the line 'self.attr = 5' executes only when __init__() is invoked on a new instance. It writes attr into the instance's own __dict__, not into the class's namespace, so the class object has no attr attribute. Every instance gets a separate copy, making this an instance-attribute assignment rather than a class-attribute definition.

D does not have a method named 'method'

Why wrong: D does not have a method named 'method' is wrong because D's class body is empty, but attribute lookup follows the method resolution order. When Python executes D().method(), it searches D first, then B, where it finds B.method, and binds that function to the instance. Thus D does have an accessible method named 'method' through inheritance, even though it is not lexically defined inside class D.

The super() call in B would call C.method

Why wrong: The statement that the super() call in B would call C.method is incorrect because B's method body simply returns 'B' and contains no super() expression. If B.method had included super().method(), then on a D instance the next class in the MRO after B would indeed be C; however, because no such super() call exists in the implementation, this hypothetical behavior never occurs.

It prints None

Why wrong: The code does not print None because the expression obj.__x never evaluates to None. After the class definition, the attribute __x is internally renamed to _ClassName__x due to name mangling, so obj.__x refers to a nonexistent attribute. Python then raises an AttributeError during attribute lookup rather than returning None, so no value is passed to print().

It raises a TypeError

Why wrong: A TypeError is not raised because the failure here is not about applying an incompatible operation or type. Name mangling renames the attribute to _ClassName__x, so obj.__x triggers an attribute lookup that fails for a missing name, which is an AttributeError. No arithmetic, concatenation, or function call is attempted, so the exception type is incorrect.

It prints 10

Why wrong: It does not print 10 because the attribute is not stored under the name __x. Name mangling transforms __x into _ClassName__x, so obj.__x points to a nonexistent attribute and causes an AttributeError before any value could be printed. The value 10 would only be accessible via the mangled name obj._ClassName__x, not through obj.__x.

Call the function with all arguments to override defaults Use the def keyword followed by the function name and parentheses Specify parameters with default values using the assignment operator Include a colon and indent the function body Write the function body with statements that use the parameters Call the function with only required arguments to use default values

Why wrong: The sequence begins by invoking the function with all arguments before the function has been defined, which violates Python's top-down execution model. At the time this call is encountered, the name is not bound to any function object, so Python raises a NameError. Defining the function must always precede any call to it, regardless of whether all arguments are supplied or defaults are used.

Use the def keyword followed by the function name and parentheses Specify parameters with default values using the assignment operator Include a colon and indent the function body Call the function with only required arguments to use default values Write the function body with statements that use the parameters Call the function with all arguments to override defaults

Why wrong: In this sequence, the function is called after the colon and indentation marker but before the body statements have been written. In valid Python source, the indented body must immediately follow the def header; a function with no body (or only a placeholder like pass) would either be a SyntaxError or an incomplete definition. Thus the call executes—or would execute—before the definition is fully assembled, which is impossible in practice: the body must be written and indented before any invocation.

Use the def keyword followed by the function name and parentheses Include a colon and indent the function body Specify parameters with default values using the assignment operator Write the function body with statements that use the parameters Call the function with only required arguments to use default values Call the function with all arguments to override defaults

Why wrong: This order incorrectly places the colon before the parameter list. Python's grammar requires the def header to be exactly "def name(params):" — the colon terminates the parameter list, so writing it earlier breaks the syntax and yields a SyntaxError. Furthermore, indentation is a property of the body block that follows the header, not a standalone step that can precede the parameter specification.