Best Practices & Design

SOLID is five design rules: each class one job, open to extend but closed to change, subtypes must be substitutable, small interfaces, depend on abstractions not concretes. In Java you use interfaces, abstract classes, and dependency injection to follow them.

DRY: don't repeat the same logic — extract it into one method. KISS: keep it simple. YAGNI: don't build features you don't need yet. Separation of concerns: each class/method does one kind of job.

The JDK is full of GoF patterns: BufferedInputStream wrapping a stream is Decorator, Comparator passed to sort is Strategy, Calendar.getInstance() is a Factory, Runnable submitted to an executor is Command, and Iterator/Iterable is the Iterator pattern.

A functional interface has one abstract method, so you can pass a lambda where it's expected. That turns patterns like Strategy into a one-line lambda instead of a whole class — e.g. passing a Comparator to sort, or a Runnable to a thread.

Patterns and SOLID earn their cost only when there's real, recurring change. If a problem is simple and stable, a plain class or method beats an interface plus a pattern. Add abstraction when a second real case appears, not on speculation.

Adapter is a wrapper that lets two incompatible interfaces work together. It takes an object with one interface and exposes it as another. In the JDK, InputStreamReader adapts a byte InputStream into a char Reader.

Builder is a way to construct an object step by step using chained method calls, then a final build() call. It avoids constructors with lots of confusing parameters, and the result is usually an immutable object.

It is a design pattern where a request passes through a series of handlers, and each one decides whether to process it or pass it along. Servlet Filters are a chain: each filter can act on a request, then call the next one.

The Command pattern wraps a request as an object so you can pass it around, store it, and run it later. In Java, Runnable and Callable are command objects: each bundles a piece of work in one method (run or call) that something else executes when it chooses.

Composite lets you treat a single object and a group of objects the same way. In Swing, both a single widget (like a JButton) and a container of widgets (like a JPanel) are Components, so code can handle either through the same Component type.

If two objects are equal by equals(), they must return the same hashCode(). So whenever you override equals(), you must also override hashCode(), or hash-based collections like HashMap and HashSet will misbehave.

equals() must be reflexive (x equals itself), symmetric (if x equals y then y equals x), transitive (if x=y and y=z then x=z), consistent (same result if nothing changes), and return false for null. Mixing a class with its subclass in equals() often breaks symmetry or transitivity.

A record auto-generates equals() and hashCode() from all its components, so equal field values mean equal objects. For a regular class, compare each significant field with Objects.equals() in equals(), and combine the same fields with Objects.hash() in hashCode().

Use instanceof for flexibility — it lets compatible types compare and is null-safe — but only if subclasses don't add fields that affect equality. Use getClass() for strict 'exactly the same class' equality, at the cost that a subclass can never equal its parent.

A hash collection records an object's hashCode() when you add it. If you then mutate a field used by hashCode(), the object's bucket changes, so the collection looks in the old bucket and can no longer find it. Use immutable keys.

An immutable object never changes after it's built. That makes it safe to share between threads with no locking, safe to cache and reuse, and safe to use as a map or set key. It's also easier to reason about because its state can't surprise you.

Make the class final so nobody can subclass it, make every field private and final, provide no setters, set all fields once in the constructor, and copy any mutable field when it goes in or comes out so outside code can't change your data.

Defensive copying means storing and returning copies of mutable objects instead of the originals. You copy in the constructor so the caller can't change your data later, and copy in the getter so the caller can't change the object you hand back. Both are needed because each closes a different leak.

A HashMap finds entries using the key's hashCode. If a key never changes, its hashCode stays the same, so the entry is always findable. If you mutate a key after putting it in, its hashCode can change and the map looks in the wrong bucket - the entry is effectively lost.

If a class can be subclassed, a subclass could add changeable fields or override methods to return different values, breaking the promise that the object never changes. You stop this by marking the class final, or by hiding the constructor (making it private) and creating instances through a static factory method.

Builder solves having too many constructor parameters. Telescoping constructors (one per combination) become unreadable and error-prone. JavaBeans setters allow building an object step by step but leave it mutable and possibly half-built. Builder gives readable, named, optional parameters and a finished immutable object.

try-with-resources declares the resource in the try header and closes it automatically when the block ends, even on exception — less code and no forgetting. Old try/finally needs a manual close() in finally, is easy to get wrong with multiple resources, and can hide the real exception if close() also throws.

A raw type is a generic class used without its type parameter, like List instead of List<String>. Avoid them because you lose compile-time type checking, so wrong types slip in and blow up at runtime with a ClassCastException.

A static factory method is a static method that returns an instance of its class instead of using new directly. You prefer it because it can have a descriptive name, can reuse cached objects, and hides how the object is built.

The target class has all-final fields and a private constructor that copies values from the builder once, so once built it can't change — that's immutable. Validating in build() means the whole object's invariants are checked together, right before it's created, instead of in isolated method calls.