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.

• ✗

  Factory pattern to instantiate processors dynamically.

  Why it's wrong here

  The Factory pattern is a creational pattern whose purpose is to encapsulate object instantiation, typically selecting a concrete class based on runtime conditions. While it could produce decorated processors if explicitly coded, the pattern itself provides no mechanism for adding logging behavior to an existing processor's process method. Using a factory here would still require altering processor classes or introducing a separate wrapper, so it does not solve the stated problem of adding logging dynamically.

• ✓

  Decorator pattern by creating a LoggingProcessor subclass that wraps another processor and calls its process method after logging.

  Why this is correct

  The Decorator pattern is correct because it lets you attach new responsibilities to an object without modifying its class. A LoggingProcessor subclass that holds a reference to another processor and invokes its process method after emitting log output is the canonical decorator implementation, preserving the processor interface while transparently adding logging. This wrapper can be applied to any processor instance at runtime and can even be stacked with other decorators.

• ✗

  Singleton pattern to ensure only one logger exists.

  Why it's wrong here

  The Singleton pattern concentrates on ensuring a logger class has at most one instance, which only addresses resource sharing and global access. It does not extend the behavior of the processor—nothing about being a singleton injects logging calls into process(). To get logging via a singleton, you would still need to modify every processor's method or wrap it separately, so the pattern is orthogonal to the requirement of enhancing processing behavior.

• ✗

  Observer pattern to notify loggers of data changes.

  Why it's wrong here

  The Observer pattern establishes a one-to-many dependency in which a subject notifies observers when its state changes, but it assumes processors are designed as observable subjects with registration and notification infrastructure. Adding a logger as an observer would require invasive changes to processor classes to maintain observer lists and broadcast events, which is fundamentally different from wrapping a single method. Here the goal is to add logging around process(), not to propagate data-change events to external listeners.