SOLID AND DESIGN PATTERNS

Question 1

What does SOLID stand for?

Answer 1

Single Responsibility
Open/Closed
Liskov Substitution
Interface Segregation
Dependency Inversion

Question 2

SOLID (in one sentence): what is it?

Answer 2

A set of OO design principles that help you build code that is easier to change, test, and extend without breaking existing behavior.

Question 3

SRP: What is the Single Responsibility Principle?

Answer 3

A class/module should have one reason to change (i.e., one primary responsibility).

Question 4

SRP: Common code smell that violates it?

Answer 4

“God” classes (e.g., OrderService that validates, calculates pricing, persists, sends emails, and logs).

Question 5

SRP: Java refactor example (high-level)

Answer 5

Split responsibilities:
- OrderValidator
- PricingService
- OrderRepository
- EmailNotifier
OrderService orchestrates.

Question 6

OCP: What is the Open/Closed Principle?

Answer 6

Software entities should be open for extension but closed for modification (add behavior without editing existing code paths).

Question 7

OCP: Typical Java technique to achieve it?

Answer 7

Program to interfaces + polymorphism.
Example: DiscountPolicy interface with implementations; add new policies without changing pricing code.

Question 8

OCP: When is a switch on type/code a red flag?

Answer 8

When every new feature requires editing the switch (violates OCP). Prefer polymorphism/registry when the set of behaviors grows.

Question 9

LSP: What is the Liskov Substitution Principle?

Answer 9

Subtypes must be substitutable for their base types without altering correctness.
(Clients using the base type shouldn’t need special-case logic.)

Question 10

LSP: Rectangle/Square classic issue (why it breaks)?

Answer 10

If Square inherits Rectangle but setters enforce equal sides, code that assumes independent width/height can fail. Prefer composition or redesign the abstraction.

Question 11

LSP: Quick checklist for a subclass

Answer 11

• Does it strengthen preconditions? (bad)
• Does it weaken postconditions? (bad)
• Does it break invariants expected by the base type? (bad)

Question 12

ISP: What is the Interface Segregation Principle?

Answer 12

Clients should not be forced to depend on methods they do not use.
Prefer several small interfaces over one “fat” interface.

Question 13

ISP: Java example

Answer 13

Instead of IMultiFunctionDevice { print(); scan(); fax(); }, use:
Printer, Scanner, Fax interfaces.
Classes implement only what they support.

Question 14

DIP: What is the Dependency Inversion Principle?

Answer 14

High-level modules should not depend on low-level modules; both should depend on abstractions.
Abstractions should not depend on details; details depend on abstractions.

Question 15

DIP: Java practice to implement it

Answer 15

Use constructor injection with interfaces.
Example: OrderService(OrderRepository repo, PaymentGateway gateway).
Avoid new ConcreteRepo() inside business logic.

Question 16

DIP vs DI: what’s the difference?

Answer 16

DIP is a design principle.
DI (Dependency Injection) is a technique/pattern to supply dependencies (often used to achieve DIP).

Question 17

Cohesion vs coupling (why SOLID cares)

Answer 17

High cohesion: related responsibilities together.
Low coupling: fewer/looser dependencies.
SOLID tends to increase cohesion and reduce coupling.

Question 18

Design Pattern: Singleton — intent

Answer 18

Intent: Ensure a class has only one instance and provide a global access point.

Question 19

Design Pattern: Singleton — Java implementation notes / pitfalls

Answer 19

Java notes: Prefer enum Singleton { INSTANCE; } for serialization safety.
Avoid using Singleton as a “global variable” (hurts testability).

Question 20

Design Pattern: Factory Method — intent

Answer 20

Intent: Define an interface for creating an object, but let subclasses decide which class to instantiate.

Question 21

Design Pattern: Factory Method — Java implementation notes / pitfalls

Answer 21

Java notes: Often a static factory (of, valueOf) or overridable create() method.
Use when creation varies by subclass/environment.

Question 22

Design Pattern: Abstract Factory — intent

Answer 22

Intent: Provide an interface for creating families of related objects without specifying concrete classes.

Question 23

Design Pattern: Abstract Factory — Java implementation notes / pitfalls

Answer 23

Java notes: Useful for UI/toolkit families, DB drivers, or platform-specific components.
Often pairs with DI: inject a factory for a family.

Question 24

Design Pattern: Builder — intent

Answer 24

Intent: Separate construction of a complex object from its representation; build step-by-step.

Question 25

Design Pattern: Builder — Java implementation notes / pitfalls

Answer 25

Java notes: Great for many optional params (avoids telescoping constructors). Immutable objects + fluent builder is common.

Question 26

Design Pattern: Prototype — intent

Answer 26

Intent: Create new objects by copying an existing prototype.

Question 27

Design Pattern: Prototype — Java implementation notes / pitfalls

Answer 27

Java notes: Prefer explicit copy constructors or `clone()` carefully. `Cloneable` is tricky; consider deep copy strategy.

Question 28

Design Pattern: Adapter — intent

Answer 28

Intent: Convert the interface of a class into another interface clients expect.

Question 29

Design Pattern: Adapter — Java implementation notes / pitfalls

Answer 29

Java notes: Wrap legacy APIs. Class adapter (inheritance) is rarer; object adapter (composition) is typical.

Question 30

Design Pattern: Bridge — intent

Answer 30

Intent: Decouple an abstraction from its implementation so both can vary independently.

Question 31

Design Pattern: Bridge — Java implementation notes / pitfalls

Answer 31

Java notes: Abstraction holds a reference to an implementation interface. Example: `Remote` (abstraction) + `Device` (implementation).

Question 32

Design Pattern: Composite — intent

Answer 32

Intent: Compose objects into tree structures to represent part-whole hierarchies; treat leaves and composites uniformly.

Question 33

Design Pattern: Composite — Java implementation notes / pitfalls

Answer 33

Java notes: Common in UI components, file systems. Ensure operations make sense for both leaf and composite.

Question 34

Design Pattern: Decorator — intent

Answer 34

Intent: Attach additional responsibilities to an object dynamically; alternative to subclassing for extension.

Question 35

Design Pattern: Decorator — Java implementation notes / pitfalls

Answer 35

Define a common interface, create a base implementation, then create decorator classes that implement the same interface and wrap another object of that interface to add behavior before or after delegating the call. Java notes: Java I/O streams are classic decorators (`BufferedInputStream`). Keep decorator interface-compatible and order-aware.

Question 36

Design Pattern: Facade — intent

Answer 36

Intent: Provide a simplified interface to a complex subsystem.

Question 37

Design Pattern: Facade — Java implementation notes / pitfalls

Answer 37

Java notes: Great at module boundaries. Facade can reduce coupling but shouldn't hide necessary domain concepts.

Question 38

Design Pattern: Flyweight — intent

Answer 38

Intent: Use sharing to support large numbers of fine-grained objects efficiently.

Question 39

Design Pattern: Flyweight — Java implementation notes / pitfalls

Answer 39

Java notes: Use caches/pools for immutable, shareable state. Separate intrinsic (shared) vs extrinsic (per-use) state.

Question 40

Design Pattern: Proxy — intent

Answer 40

Intent: Provide a surrogate or placeholder to control access to another object.

Question 41

Design Pattern: Proxy — Java implementation notes / pitfalls

Answer 41

Java notes: Common with lazy loading, access control, remote stubs. Java dynamic proxies / bytecode proxies (e.g., AOP) implement this.

Question 42

Design Pattern: Chain of Responsibility — intent

Answer 42

Intent: Pass a request along a chain of handlers; each can handle or pass on.

Question 43

Design Pattern: Chain of Responsibility — Java implementation notes / pitfalls

Answer 43

Java notes: Build pipelines/filters (logging, auth, validation). Beware of missing terminal handler; define default behavior.

Question 44

Design Pattern: Command — intent

Answer 44

Intent: Encapsulate a request as an object, allowing parameterization, queuing, logging, and undo.

Question 45

Design Pattern: Command — Java implementation notes / pitfalls

Answer 45

Java notes: Use functional interfaces/lambdas for simple commands. Store history for undo/redo.

Question 46

Design Pattern: Iterator — intent

Answer 46

Intent: Provide a way to access elements of an aggregate sequentially without exposing its underlying representation.

Question 47

Design Pattern: Iterator — Java implementation notes / pitfalls

Answer 47

Java notes: `Iterator`/`Iterable` built-in. Prefer fail-fast iterators when structure changes unexpectedly.

Question 48

Design Pattern: Mediator — intent

Answer 48

Intent: Define an object that encapsulates how a set of objects interact; promotes loose coupling.

Question 49

Design Pattern: Mediator — Java implementation notes / pitfalls

Answer 49

Java notes: Useful in UI dialogs or workflow coordinators. Avoid turning mediator into a "god" object.

Question 50

Design Pattern: Memento — intent

Answer 50

Intent: Capture and externalize an object's internal state so it can be restored later without violating encapsulation.

Question 51

Design Pattern: Memento — Java implementation notes / pitfalls

Answer 51

Java notes: Used for undo snapshots. Be careful about memory usage; consider incremental diffs.

Question 52

Design Pattern: Observer — intent

Answer 52

Intent: Define a one-to-many dependency so when one object changes state, all dependents are notified.

Question 53

Design Pattern: Observer — Java implementation notes / pitfalls

Answer 53

Java notes: `java.util.Observable/Observer` are deprecated; roll your own or use `PropertyChangeSupport`, reactive streams, etc. Avoid memory leaks: unsubscribe.

Question 54

Design Pattern: State — intent

Answer 54

Intent: Allow an object to alter its behavior when its internal state changes; object appears to change its class.

Question 55

Design Pattern: State — Java implementation notes / pitfalls

Answer 55

Java notes: Represent states as classes implementing a `State` interface. Good when many state-specific branches (`if/switch`) appear.

Question 56

Design Pattern: Strategy — intent

Answer 56

Intent: Define a family of algorithms, encapsulate each, and make them interchangeable.

Question 57

Design Pattern: Strategy — Java implementation notes / pitfalls

Answer 57

Java notes: Use interfaces or lambdas (`Comparator`, `Predicate`). Prefer for runtime selection of behavior.

Question 58

Design Pattern: Template Method — intent

Answer 58

Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.

Question 59

Design Pattern: Template Method — Java implementation notes / pitfalls

Answer 59

Java notes: Use abstract base class with `final` template method. Prefer composition/strategies if subclassing becomes rigid.

Question 60

Design Pattern: Visitor — intent

Answer 60

Intent: Represent an operation to be performed on elements of an object structure without changing the element classes.

Question 61

Design Pattern: Visitor — Java implementation notes / pitfalls

Answer 61

Java notes: Useful with stable object structures + many operations. Double-dispatch can be verbose; consider pattern matching alternatives (when available).

Question 62

Factory Method vs Abstract Factory (key difference)?

Answer 62

Factory Method: varies **one product** via subclassing/overriding. Abstract Factory: creates **families of related products** via a factory object.

Question 63

Decorator vs Proxy (how to tell them apart)?

Answer 63

Decorator adds behavior/feature. Proxy controls access (lazy, remote, security) and aims to be transparent.

Question 64

Adapter vs Facade (difference)?

Answer 64

Adapter makes one thing look like another (interface conversion). Facade offers a simpler front to a complex subsystem (simplification).

Question 65

Strategy vs State (difference)?

Answer 65

Strategy: caller chooses an algorithm (usually stateless) from a set. State: object changes behavior based on internal state transitions.

Question 66

Composition over inheritance (why)?

Answer 66

Composition is more flexible: change behavior by swapping collaborators instead of being locked into an inheritance hierarchy. Helps with OCP and LSP.

Question 67

When should you avoid patterns?

Answer 67

When simple code is clearer. Patterns add indirection; use them to solve repeated/complex change problems, not as decoration.

Question 68

What is "program to an interface" (in Java)?

Answer 68

Depend on `interface`/abstract types rather than concrete classes. This enables substitution (testing, swapping implementations) and supports OCP/DIP.

Question 69

What is the role of UML-like participants in GoF patterns (Creator/Client/Receiver etc.)?

Answer 69

They describe **responsibilities** (who creates, who calls, who implements) so you can map the idea into your codebase regardless of language/framework.

Question 70

SOLID vs design patterns (relationship)?

Answer 70

SOLID = principles (guidelines). Design patterns = reusable solutions to recurring design problems. Patterns often help you apply SOLID, but are not mandatory.

Question 71

How do you spot an overused Singleton?

Answer 71

When many classes call `Singleton.getInstance()` (hidden dependency), tests are hard, and state leaks between tests. Prefer DI + explicit dependencies.