PCAP Object-Oriented Programming Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use class variables to store defaults.

  Why it's wrong here

  Class variables are shared by all instances of the class, so using them to hold default values means every instance sees the same underlying object. If any code assigns to an instance attribute to override the default, it must explicitly shadow the class variable; worse, if the default is mutable (e.g., a list or dict), mutations through one instance will leak to every other instance. This conflates class-level state with per-instance initialization state, introducing subtle side effects that default parameter values avoid.

• ✓

  Use default parameter values in the __init__ signature.

  Why this is correct

  Defining default parameter values in the __init__ signature is the canonical Python idiom for optional constructor arguments. These defaults are evaluated once at function definition time, but for immutable types (like None, int, str) that is harmless because rebinding a parameter simply rebinds the local name. This approach requires no extra code, allows callers to omit the argument or pass it by keyword, and keeps all initialization logic inside the constructor.

• ✗

  Override __new__ to set default values.

  Why it's wrong here

  Overriding __new__ to set default values is inappropriate because __new__ is a static method whose sole job is to allocate and return a new instance; it runs before __init__ and receives the same arguments but is not intended for normal attribute initialization. In practice, you would have to replicate the instance attribute assignment logic there and still let __init__ run, leading to duplicated or confusing code. It also makes subclassing more difficult, since __new__ must cooperate with the parent's behavior, which is why __init__ is the conventional place for optional-argument defaults.

• ✗

  Use a separate setter method called after instantiation.

  Why it's wrong here

  Requiring a separate setter method to be called after instantiation breaks the constructor's contract by leaving the object in an incomplete state until the caller remembers to invoke the setter. This is not a standard pattern for optional constructor defaults because it obscures the initialization logic, invites errors from forgotten calls, and makes the API less discoverable. Python's design expects __init__ to perform all necessary initialization, so optional arguments should be handled there rather than deferred to a second call.