Java SOLID and design judgement

Asked in almost every round from two years upward, and usually answered by reciting the acronym rather than applying it.

3 concepts · 11 interview questions

What this topic covers

Every concept in solid and design judgement, and the questions each one gets asked as. Where a question links, it has a full write-up.

The five principles

Five heuristics about where to put change. They are guidance about coupling, not laws, and each has a cost when applied without a reason.

  • Explain the single responsibility principle with an example from your code.
  • What does the open-closed principle mean in practice?
  • What breaks the Liskov substitution principle?
  • Why prefer several small interfaces over one large one?
  • What is dependency inversion, and how is it different from dependency injection?

Patterns applied too eagerly

Every pattern adds indirection. Applied without the pressure it was designed for, it makes code harder to follow while looking disciplined.

  • When is a design pattern the wrong answer?
  • What is a service locator, and why is it worse than injection?
  • What is an anemic domain model, and is it always wrong?

Recognising when to change the design

The signal usually arrives as friction: a change touching many files, a class needing many collaborators, or a test that is hard to set up.

  • What tells you a class is doing too much?
  • How do you refactor safely without tests?
  • When do you leave bad code alone?

More in Design patterns

See the whole reference map →