Design Patterns practice questions

Use the @abstractmethod decorator

Why wrong: This forces overriding rather than preventing it.

Use the @staticmethod decorator

Why wrong: Static methods can still be overridden in subclasses.

Use the private keyword

Why wrong: Python does not have a private keyword.

Raise NotImplementedError in the base class instead of using decorators

Why wrong: While this works, it is not the standard Pythonic approach using the abc module.

Define the method as a static method using @staticmethod

Why wrong: Factory methods usually require instance context or class-level context, not static methods.

Use the @abstractmethod decorator on the concrete implementation

Why wrong: The @abstractmethod decorator is for the base class, not the concrete implementation.

Setting the class variable __instance__ to None in the global scope

Why wrong: Global variables are not thread-safe and do not leverage the metaclass structure properly.

Overriding the __init__ method of the object class

Why wrong: Overriding __init__ does not prevent instance creation, which occurs in __new__ or via the metaclass.

Using the __new__ method of the target class instead of the metaclass

Why wrong: The __new__ method of the target class is called after the metaclass has already processed the class creation.

Use a global list of observers to manage them centrally

Why wrong: A global list increases coupling and doesn't solve the memory leak issue.

Set the Observer list to None after every notification cycle

Why wrong: This would remove all observers, preventing future notifications.

Explicitly call the detach method for every Observer

Why wrong: This requires manual management and is prone to errors if observers are short-lived.

Use the Python 'copy' module to clone the document before every command

Why wrong: Cloning is expensive and doesn't explicitly store the logic required for reversal.

Store the entire document object in the command history

Why wrong: This is memory-intensive and inefficient for large documents.

Re-execute the entire command history up to the point of the undo

Why wrong: Re-executing the entire history is inefficient and complex.

Use the @property decorator to trigger instantiation immediately upon object creation

Why wrong: This would trigger initialization immediately, defeating the purpose of lazy loading.

Overload the __del__ method to release the resource

Why wrong: The __del__ method manages cleanup, not initialization.

Use a try-except block around the Proxy's constructor

Why wrong: The constructor should remain lightweight; the heavy object is loaded on demand.

The Facade must inherit from every class in the subsystem

Why wrong: Inheritance creates tight coupling, which the Facade aims to reduce.

The Facade must implement the Singleton pattern to ensure only one interface exists

Why wrong: A Facade does not need to be a Singleton; it is a structural interface.

The Facade should expose all methods of the subsystem classes for flexibility

Why wrong: Exposing all methods defeats the purpose of simplifying the interface.

The abstract state base class

Why wrong: The base class defines the interface, not the logic for transitions.

A separate controller object

Why wrong: This would violate the encapsulation of the state machine logic.

The client code

Why wrong: The client should ideally interact with the context, not manually transition internal states.

By querying the client for the next handler

Why wrong: This violates the decoupling principle of the chain.

By using an exception to jump to the next handler

Why wrong: Exceptions are for error handling, not control flow in chains.

By returning True from a base handler method

Why wrong: Return values generally do not manage the chain delegation logic.

Use a global variable for the strategy

Why wrong: Global state makes the code harder to test and maintain.

Import the strategy module inside the context's run method

Why wrong: This is inefficient and hides dependencies.

Hardcode the strategy class inside the context's __init__ method

Why wrong: This creates tight coupling and violates the strategy pattern intent.

It automatically implements the Singleton pattern

Why wrong: It has nothing to do with Singleton.

It prevents the decorator from being applied multiple times

Why wrong: It does not restrict multiple applications.

It ensures the function runs faster

Why wrong: It has no performance impact.

Both copies result in the same memory address

Why wrong: Both create new objects with different memory addresses.

Shallow copy clones nested objects, deep copy does not

Why wrong: This is the reverse of the actual behavior.

Deep copy is always faster than shallow copy

Why wrong: Deep copy is generally slower due to recursion.

Both are shared, but intrinsic is stored in a database

Why wrong: Storage location is not the defining characteristic of these states.

Neither state can be changed once the Flyweight is instantiated

Why wrong: Extrinsic state is mutable by definition as it depends on the specific context.

Intrinsic state is the unique data, extrinsic is the shared data

Why wrong: This is the exact opposite of the definition.

It requires the Leaf objects to also implement the same parent reference logic

Why wrong: While true, the challenge is the maintenance of these references across the structure.

It makes the children too independent

Why wrong: The goal is to manage children, not make them independent.

Python's memory management cannot handle circular references

Why wrong: Python handles circular references well via garbage collection.

Single Responsibility Principle

Why wrong: While it isolates interface adaptation, it's not the primary principle.

Dependency Inversion Principle

Why wrong: While related, the Adapter's primary goal is interface compatibility.

Liskov Substitution Principle

Why wrong: Adapter often violates Liskov because it wraps objects, it doesn't necessarily fulfill the base class interface.

The implementation must use a Singleton to manage its state

Why wrong: Singleton is not a requirement for the Bridge pattern.

Both the abstraction and the implementation must inherit from the same class

Why wrong: This would create a single hierarchy, failing the decoupling goal.

The implementation must be a subclass of the abstraction

Why wrong: This would bind them together, defeating the pattern.

The Caretaker

Why wrong: The Caretaker holds the Memento but should not know its contents.

The Originator's public properties

Why wrong: Public properties would expose internal state, violating encapsulation.

A global database

Why wrong: This is not part of the Memento pattern design.

Adding new behaviors to an object at runtime

Why wrong: This is the Decorator pattern.

Creating a simple object with no parameters

Why wrong: This is overkill for simple objects.

Ensuring only one instance of a class exists

Why wrong: This is the Singleton pattern.

It prevents the element from needing to know about the visitor

Why wrong: The element must have an 'accept' method that knows about the visitor interface.

It allows the visitor to access private methods of the element

Why wrong: Visitor does not override access control.

It allows the visitor to be defined as a singleton

Why wrong: Visitor pattern does not require Singletons.

Proxy

Why wrong: Proxy controls access to another object.

Singleton

Why wrong: Singleton limits the number of instances.

Builder

Why wrong: Builder is for step-by-step construction of complex objects.