Recommended
Practice
1. Trace the sequence of events when a client requests a service via Dependency Injection (DI) in an IoC container. Which step correctly follows the previous?
easy
Solution
Step 1: Understand DI and IoC flow
In Dependency Injection via IoC, the client requests a service from the container, which manages creation and injection.Step 2: Analyze options
Client requests the service from the IoC container, which then creates and injects dependencies into the client. correctly describes the client requesting the service and the container creating and injecting dependencies. Client creates the service instance directly, then passes it to the IoC container. reverses roles incorrectly. IoC container instantiates the service and injects it into the client before the client uses it. suggests container injects before client requests, which is inaccurate. Service creates the client instance and injects itself into the client. incorrectly states the service creates the client.Final Answer:
Option B -> Option BQuick Check:
IoC container controls creation; client depends on container to provide dependencies.
Hint: In DI, client asks container; container creates and injects dependencies.
Common Mistakes:
- Thinking client creates service instances directly
- Assuming container injects dependencies before client requests
- Confusing who controls object creation
2. You need to traverse a tree-like structure where each node can be either a single element or a composite containing multiple child elements. The traversal should allow clients to iterate over all elements uniformly without exposing the internal structure. Which design approach best fits this requirement?
easy
Solution
Step 1: Understand the problem structure
The problem involves a tree with nodes that can be leaves or composites containing children, requiring uniform traversal.Step 2: Identify the suitable pattern
The Composite pattern allows treating individual objects and compositions uniformly, and combining it with an Iterator abstracts traversal details.Final Answer:
Option A -> Option AQuick Check:
Composite + Iterator provides uniform traversal abstraction [OK]
Hint: Composite + Iterator unifies traversal of tree structures [OK]
Common Mistakes:
- Confusing traversal with greedy or DP approaches
- Using manual recursion without abstraction
3. Identify the bug in the following singleton implementation that aims to use lazy initialization with double-checked locking in Java-like pseudocode:
class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}medium
Solution
Step 1: Analyze double-checked locking correctness
Without volatile, the instance reference may be visible before full construction due to instruction reordering.Step 2: Check other options
Synchronized block size is minimal and correct; first null check is necessary for performance; constructor privacy is unrelated to this snippet.Final Answer:
Option B -> Option BQuick Check:
Missing volatile causes subtle thread-safety bugs [OK]
Hint: Volatile prevents instruction reordering in double-checked locking [OK]
Common Mistakes:
- Ignoring volatile keyword necessity
- Thinking synchronized block size is the bug
- Assuming constructor privacy is the main issue here
4. Examine the following buggy code implementing the Template Method Pattern. Which line contains the subtle bug that breaks the pattern's intended behavior?
medium
Solution
Step 1: Identify overridden methods
Tea overrides prepare_recipe, which breaks the template method pattern by duplicating and changing the algorithm flow.Step 2: Understand impact
Overriding the template method in subclass bypasses the base class skeleton, causing inconsistent behavior and code duplication.Final Answer:
Option A -> Option AQuick Check:
Template method must not be overridden by subclasses [OK]
Hint: Overriding template method breaks algorithm skeleton [OK]
Common Mistakes:
- Thinking overriding abstract methods is bug
- Ignoring hook method usage
5. If a new requirement arises where an interface needs to add a method without breaking existing implementations, what is the best approach to handle this in a language that originally did not support default methods in interfaces?
hard
Solution
Step 1: Understand backward compatibility
Adding a method directly to an interface breaks existing implementers if no default implementation exists.Step 2: Why converting to abstract class is problematic
Changing interface to abstract class breaks existing multiple inheritance and design contracts.Step 3: Using interface extension
Creating a new interface that extends the original preserves backward compatibility and allows gradual adoption.Step 4: Static methods in interfaces
Static methods do not affect instance method contracts and cannot replace instance methods.Final Answer:
Option B -> Option BQuick Check:
Extending interfaces is the safe way to evolve contracts without breaking clients.
Hint: Extend interfaces to add methods without breaking existing code.
Common Mistakes:
- Assuming all implementers can update immediately.
- Thinking abstract classes can replace interfaces without impact.
- Confusing static methods with instance methods in interfaces.