The Facade pattern becomes a liability when the simplified interface hides functionality or control that clients genuinely need. It trades granularity for convenience, and in situations demanding fine-grained control, that trade works against you.
Key Points: • When clients need direct access to specific subsystem features, a facade can block or complicate that access. • Facades can mask performance bottlenecks inside the subsystem, since callers only see the simplified surface. • Debugging becomes harder because problems inside the subsystem are less visible through the facade's abstraction. • Adding a facade "by default" over a subsystem that's already simple just adds an unnecessary layer of indirection. • A facade that grows to expose every subsystem method eventually becomes a maintenance burden rather than a simplification.
Interview Tip: A concise interview answer is:
"A facade is a bad idea when callers actually need fine-grained control over the subsystem, because the simplified interface can hide the specific method or performance knob they need. It's also unnecessary when the underlying subsystem is already simple, since you'd just be adding an indirection layer with no real benefit."