पाठ 24 / 25

Patterns in Interviews and Code Review

Recognise, name and justify.

Naming patterns with judgement

In design interviews and reviews, patterns are useful as shared vocabulary: "this is a Strategy keyed by payment method" says a lot in a few words. Strong answers follow a shape: name the problem (what varies, what must stay stable), propose the pattern, explain the trade-off, and mention the simpler alternative ("a map of functions would also work here"). Interviewers often probe when not to use a pattern, the difference between look-alikes (Decorator vs Proxy vs Adapter, Strategy vs State, Factory vs Builder), and modern equivalents (DI containers, middleware, event emitters). In code review, prefer questions to labels: "Do we expect another implementation soon?" is more helpful than "this violates SOLID". Recognising patterns in frameworks you already use (middleware, hooks, iterators, observers) is a good way to practise.

Telling look-alikes apart

Compare intent, not structure.

Adapter    vs Decorator   changes the interface     vs keeps it, adds behaviour
Decorator  vs Proxy       adds behaviour            vs controls access (cache, lazy, auth)
Facade     vs Adapter     new simpler interface     vs match an existing expected interface
Strategy   vs State       client picks algorithm    vs object switches behaviour as state changes
Factory    vs Builder     decides which class       vs assembles one complex object in steps
Observer   vs Pub/Sub     subject knows listeners   vs broker decouples publisher and subscriber
Command    vs Strategy    a request to run/undo     vs an interchangeable algorithm

Lead with the problem

Saying "we have three ways to calculate shipping that change per campaign" before "let us use Strategy" keeps the discussion grounded and shows you are not pattern-hunting.

त्वरित जाँच: What distinguishes Strategy from State?

  • They solve unrelated problems and look nothing alike
  • Strategy requires inheritance and State does not
  • With Strategy the client chooses the algorithm; with State the object changes behaviour as its own state changes
  • State is creational and Strategy is structural
Answer

With Strategy the client chooses the algorithm; with State the object changes behaviour as its own state changes — Same structure, different intent.