B3.2 Fundamentals of OOP for multiple classes (HL only)

The system requires that only one PrinterManager instance can ever exist, and all departments must share that same instance. This is the classic problem the Singleton pattern solves.

The Singleton pattern requires: (1) a private constructor to block external instantiation, (2) a private static variable holding the single instance, and (3) a public static method (e.g., getInstance()) that creates the instance on first call and returns it on every subsequent call.

The option that states "Make the constructor private, store a single instance as a private static variable, and expose it through a public static method" matches all three Singleton requirements precisely.

This is the standard, well-recognised implementation of the Singleton pattern in both Java and Python. It is the only option that actually prevents multiple instances from being created.

The question asks for the OOP technique that guarantees at most one instance of a class exists throughout a program.

"Declare the class as abstract" is incorrect. An abstract class cannot be instantiated at all — subclasses could still each create their own instances, so this does not guarantee a single shared instance.

"Use aggregation so that multiple departments hold a reference to the same externally created object" describes dependency injection or aggregation, not a pattern that enforces single instantiation. Nothing prevents a second instance from being created.

"Override __eq__" only changes how equality is evaluated — two separate objects can still exist in memory. It does nothing to prevent the creation of multiple instances.

The remaining option — private constructor + private static instance + public static accessor method — is the textbook Singleton implementation and the only one that truly restricts instantiation to a single object.

The loop calls the same method play() on each element of ensemble. The elements are a mixture of Guitar and Flute objects, which each override play() with different implementations.

Polymorphism is the ability of different objects to respond to the same method call in different ways. Here, play() returns "Strumming chords" for Guitar and "Blowing a melody" for Flute — different results from an identical call.

Both Guitar and Flute override the play() method from Instrument. The correct version is selected at runtime based on the object's actual type — this is dynamic (runtime) polymorphism.

The option "Polymorphism, because the same method call produces different behaviour depending on the actual object type" precisely matches the definition and the code behaviour.

The question asks which OOP concept is primarily demonstrated by the loop calling play() on a heterogeneous list of objects.

"Encapsulation" refers to hiding internal data behind an interface. While the method body is not shown to the caller, the question focuses on the varied runtime behaviour of play(), not on data hiding. This is not the primary concept demonstrated.

"Abstraction" relates to defining common interfaces (often via abstract classes). The base Instrument class does provide a common interface, but the loop behaviour — different outputs from the same call — demonstrates polymorphism, not abstraction.

"Composition" is a has-a relationship where one class owns instances of another. A list containing Instrument objects is not composition in the OOP design sense — there is no ownership relationship between a class and a list variable.

Polymorphism is the only concept that directly explains why the same play() call yields "Strumming chords" for one object and "Blowing a melody" for another.