Question 1

What is the Visitor pattern and when should you use it?

Accepted Answer

A pattern that separates an algorithm from the object structure it operates on — adding new operations to a stable class hierarchy without modifying existing classes. Add accept(Visitor v) to each class; the Visitor implements visit(ConcreteA), visit(ConcreteB). Adding a new operation = new Visitor class, no class changes. Trade-off: adding a new element class requires updating all Visitors. Ideal when operations change more often than the type hierarchy.

Question 2

What is the Command pattern and how does it enable undo/redo?

Accepted Answer

Encapsulates a request as an object with execute() and undo() methods — a history stack of executed Commands enables undo by calling undo() in reverse order. Editor: bold text = BoldCommand(editor, selection). execute() applies bold; undo() removes it. Store commands in a list for undo/redo. Also enables queuing, logging, and delayed execution. Used in GUI frameworks, transaction systems, and game engines.

Question 3

What is the difference between the Proxy and Decorator patterns?

Accepted Answer

Proxy controls access to an object (same interface, e.g., lazy loading, access control, logging); Decorator adds new behavior (same interface, typically composable and stackable). Proxy: the client doesn't know it's talking to a proxy — used for virtual proxies (lazy load), protection proxies (auth check), remote proxies (RPC). Decorator: explicitly adds behavior (Logging + Caching + Retry decorators stacked). Intent differs despite similar structure.

Question 4

What is event sourcing?

Accepted Answer

Storing the sequence of domain events that led to the current state, rather than just storing the current state — enables full audit trail, time travel, and event replay. Instead of UPDATE account SET balance = 500, store: MoneyDeposited(100), MoneyWithdrawn(50), MoneyDeposited(450). Current state = replay of all events. Enables: audit log, temporal queries ('what was the state on Jan 1?'), event-driven microservices via event streams.

Question 5

What is CQRS (Command Query Responsibility Segregation)?

Accepted Answer

Separating the read model (queries) from the write model (commands) — allowing each to be independently optimized, scaled, and modeled. Write side: domain model, rich validation, event sourcing. Read side: denormalized views optimized for specific queries (no joins needed). Scales reads independently. Often paired with event sourcing. Trade-off: eventual consistency between write and read models.

OOP Concepts — Senior Dev Interview Questions

More Senior Dev Topics

OOP Concepts at Other Levels