5e:["$","code","code-3",{"children":"- isAdult(age: int): boolean"}] 5f:[["$","p","p-0",{"children":"How is an interface different from an abstract class in a diagram?"}]] 60:[["$","p","p-0",{"children":["An interface has the label ",["$","code","code-0",{"children":"<>"}],", lists only methods, and has no attributes. A class connects to it with a dashed line and a hollow triangle. An abstract class has the label ",["$","code","code-1",{"children":"<>"}]," and an italic name. It can have attributes and methods with bodies. A child class connects to it with a solid line and a hollow triangle."]}]] 61:[["$","p","p-0",{"children":"How is an enum shown?"}]] 62:[["$","p","p-0",{"children":["It is a box with the label ",["$","code","code-0",{"children":"<>"}]," above the name, and the values listed below. Classes that use the enum have an arrow pointing to it."]}]] 63:[["$","p","p-0",{"children":"What are the three perspectives of a class diagram?"}]] 64:[["$","p","p-0",{"children":"Conceptual shows only the main things and how the business relates them. It is for analysts and domain experts. Specification shows interfaces, abstract classes and the key public methods. It is for architects and designers. Implementation shows every attribute and method with visibility and types. It is for developers."}]] 65:[["$","p","p-0",{"children":"What is the difference between aggregation and composition?"}]] 66:[["$","p","p-0",{"children":"Both mean a whole has parts. In aggregation the parts can live without the whole, like professors in a department. It uses a hollow diamond. In composition the parts die with the whole, like rooms in a house. It uses a filled diamond. The diamond is always on the whole's side."}]] 67:[["$","p","p-0",{"children":"Which arrow end means inheritance and which means realization?"}]] 68:[["$","p","p-0",{"children":"Both use a hollow triangle that points at the parent. Inheritance uses a solid line. Realization, which is a class implementing an interface, uses a dashed line."}]] 69:[["$","p","p-0",{"children":"How much detail should you put in a class diagram?"}]] 6a:[["$","p","p-0",{"children":"Only as much as the reader needs. For business people, show names and relationships. For a design discussion, show interfaces and the key public methods. Show every field and method only when developers are about to write the code."}]] 6b:[["$","p","p-0",{"children":"What is the difference between coupling and cohesion?"}]] 6c:[["$","p","p-0",{"children":"Coupling is how much one class depends on others. Cohesion is how well the parts inside one class belong together. You want low coupling and high cohesion."}]] 6d:[["$","p","p-0",{"children":"Name the types of coupling from worst to best."}]] 6e:[["$","p","p-0",{"children":"Content, common (global state), external (a shared outside format), control, stamp, data and message. Content coupling reaches into another class's internals. Message coupling uses only messages or events."}]] 6f:[["$","p","p-0",{"children":"What is control coupling? How do you remove it?"}]] 70:[["$","p","p-0",{"children":["A caller passes a flag that tells the callee which path to take, like ",["$","code","code-0",{"children":"notifyCustomer(order, true)"}]," for SMS. The caller ends up knowing the callee's internals. Replace it with separate methods or with polymorphism, like a ",["$","code","code-1",{"children":"Notifier"}]," interface with SMS and push implementations."]}]] 71:[["$","p","p-0",{"children":"How can you tell a class has low cohesion?"}]] 72:[["$","p","p-0",{"children":["You cannot describe it in one sentence without \"and\", its methods use different fields, and it changes for many unrelated reasons. ",["$","code","code-0",{"children":"OrderUtils"}]," is the usual example."]}]] 73:[["$","p","p-0",{"children":"How does dependency injection reduce coupling?"}]] 74:[["$","p","p-0",{"children":"The class receives its dependencies, usually as interfaces, through the constructor instead of creating them. It does not know which concrete class it uses, so you can swap implementations or pass fakes in tests."}]] 75:[["$","p","p-0",{"children":"How would you check if a codebase is tightly coupled?"}]] 76:[["$","p","p-0",{"children":"Count how many files change for one small feature, and check whether you can unit test a class without a database or network. Long constructors, global state and tests that break in unrelated areas are other signs."}]] 77:[["$","p","p-0",{"children":"Can you have too little coupling?"}]] 78:[["$","p","p-0",{"children":"Yes. Turning every call into an event or wrapping every class in an interface makes the flow hard to follow and adds code for no benefit. Some coupling is needed for the system to work. Keep it to simple, stable interfaces."}]] 79:[["$","p","p-0",{"children":"Why is String immutable in Java?"}]] 7a:[["$","p","p-0",{"children":"So the string pool can safely share one copy of each literal, so a validated path or URL cannot change after the check, so the hashCode can be cached, and so threads can share strings without locks."}]] 7b:[["$","p","p-0",{"children":["What is the difference between a string literal and ",["$","code","code-0",{"children":"new String(...)"}],"?"]}]] 7c:[["$","p","p-0",{"children":["The literal comes from the string pool and is reused. ",["$","code","code-0",{"children":"new String"}]," always creates a new object on the heap, even if the same text is already in the pool, so ",["$","code","code-1",{"children":"=="}]," between the two is false."]}]] 7d:[["$","p","p-0",{"children":["Why should you not use ",["$","code","code-0",{"children":"+="}]," on a String inside a loop?"]}]] 7e:[["$","p","p-0",{"children":["Each ",["$","code","code-0",{"children":"+="}]," creates a new String and copies every character so far, so the total work grows with the square of the loop size. ",["$","code","code-1",{"children":"StringBuilder"}]," appends into one buffer and stays linear."]}]] 7f:[["$","p","p-0",{"children":"StringBuilder or StringBuffer?"}]] 80:[["$","p","p-0",{"children":"StringBuilder. StringBuffer synchronizes every method, which costs time, and a builder is almost always a local variable that only one thread uses."}]] 81:[["$","p","p-0",{"children":"How do you make a class immutable?"}]] 82:[["$","p","p-0",{"children":"Make the class final, every field private and final, no setters, copy mutable inputs in the constructor, and return copies or unmodifiable versions from getters. Methods that change something return a new object."}]] 83:[["$","p","p-0",{"children":["Is ",["$","code","code-0",{"children":"List.copyOf"}]," the same as ",["$","code","code-1",{"children":"Collections.unmodifiableList"}],"?"]}]] 84:[["$","p","p-0",{"children":["No. ",["$","code","code-0",{"children":"List.copyOf"}]," takes a snapshot, so later changes to the source do not show. ",["$","code","code-1",{"children":"unmodifiableList"}]," is a read only view, so changes to the source still show through it."]}]] 85:[["$","p","p-0",{"children":"Is Java pass by value or pass by reference?"}]] 86:[["$","p","p-0",{"children":"Always pass by value. For objects, the value being copied is the reference, so a method can change the object it points to but cannot make the caller's variable point to a different object."}]] 87:[["$","p","p-0",{"children":["Why does ",["$","code","code-0",{"children":"Integer a = 128, b = 128; a == b"}]," print false?"]}]] 88:[["$","p","p-0",{"children":[["$","code","code-0",{"children":"Integer.valueOf"}]," caches objects only for -128 to 127. 128 gives two different objects, and ",["$","code","code-1",{"children":"=="}]," compares references. Use ",["$","code","code-2",{"children":"equals"}]," for wrappers."]}]] 89:[["$","p","p-0",{"children":"What is stored on the stack and what on the heap?"}]] 8a:[["$","p","p-0",{"children":"The stack holds method frames with local variables and parameters, including local references. All objects and arrays live on the heap, including the fields inside them, and the heap is shared by all threads."}]] 8b:[["$","p","p-0",{"children":"How does the garbage collector decide an object can be removed?"}]] 8c:[["$","p","p-0",{"children":"It starts from GC roots such as local variables in active frames, static fields and live threads, and follows references. Anything it cannot reach is garbage, even if it is part of a cycle."}]] 8d:[["$","p","p-0",{"children":"Can a Java program have a memory leak?"}]] 8e:[["$","p","p-0",{"children":"Yes. If unneeded objects stay reachable, the GC cannot remove them. Common causes are static collections that only grow, listeners that are never removed, and caches with no size limit."}]] 8f:[["$","p","p-0",{"children":"What is the difference between OutOfMemoryError and StackOverflowError?"}]] 90:[["$","p","p-0",{"children":"OutOfMemoryError means the heap is full, usually from a leak or loading too much data. StackOverflowError means one thread's stack is full, almost always from recursion with no base case."}]] 91:[["$","p","p-0",{"children":["What is the difference between ",["$","code","code-0",{"children":"orElse"}]," and ",["$","code","code-1",{"children":"orElseGet"}],"?"]}]] 92:[["$","p","p-0",{"children":[["$","code","code-0",{"children":"orElse"}]," takes a value, so its argument is always evaluated, even when the Optional has a value. ",["$","code","code-1",{"children":"orElseGet"}]," takes a supplier that runs only when the Optional is empty, so use it when the default is expensive."]}]] 93:[["$","p","p-0",{"children":"Where should you use Optional?"}]] 94:[["$","p","p-0",{"children":["As the return type of methods that may have no result, like ",["$","code","code-0",{"children":"findUserById"}],". Not for fields, method parameters or collections, and never return ",["$","code","code-1",{"children":"null"}]," from a method that returns Optional."]}]] 95:[["$","p","p-0",{"children":["What is the difference between ",["$","code","code-0",{"children":"map"}]," and ",["$","code","code-1",{"children":"flatMap"}]," on Optional?"]}]] 96:[["$","p","p-0",{"children":[["$","code","code-0",{"children":"map"}]," wraps the function's result in an Optional. If the function already returns an Optional, ",["$","code","code-1",{"children":"map"}]," gives you ",["$","code","code-2",{"children":"Optional>"}],", and ",["$","code","code-3",{"children":"flatMap"}]," flattens that to ",["$","code","code-4",{"children":"Optional"}],"."]}]] 97:[["$","p","p-0",{"children":["What does ",["$","code","code-0",{"children":"Objects.requireNonNull"}]," give you?"]}]] 98:[["$","p","p-0",{"children":"It throws a NullPointerException with your message the moment a null comes in, usually in the constructor. The failure then points at the caller who passed the null instead of some later line that used it."}]] 99:[["$","p","p-0",{"children":"Should a method that returns a list return null when there are no results?"}]] 9a:[["$","p","p-0",{"children":"No. Return an empty list. Callers can loop over it safely without a null check, and empty already means \"no results\"."}]] 9b:[["$","p","p-0",{"children":"What is the Null Object pattern?"}]] 9c:[["$","p","p-0",{"children":["Instead of using null for \"nothing\", you pass an object that implements the same interface and does nothing, like a ",["$","code","code-0",{"children":"NoDiscount"}]," that returns the amount unchanged. Callers stop checking for null. Only use it when doing nothing is the right default."]}]] 9d:[["$","p","p-0",{"children":"What does a record give you for free?"}]] 9e:[["$","p","p-0",{"children":["Private final fields, a canonical constructor, accessor methods named after the fields, and ",["$","code","code-0",{"children":"equals"}],", ",["$","code","code-1",{"children":"hashCode"}]," and ",["$","code","code-2",{"children":"toString"}]," based on all fields. It is final and cannot extend another class."]}]] 9f:[["$","p","p-0",{"children":"Is a record immutable?"}]] a0:[["$","p","p-0",{"children":["Only shallowly. The fields are final, but if one holds a mutable list, that list can still change. Copy it with ",["$","code","code-0",{"children":"List.copyOf"}]," in a compact constructor to make it truly immutable."]}]] a1:[["$","p","p-0",{"children":"Why would you not use a record for a JPA entity?"}]] a2:[["$","p","p-0",{"children":"JPA needs a no argument constructor, mutable fields and non final classes so it can create proxies and load data in. Records are final with final fields and no no-arg constructor."}]] a3:[["$","p","p-0",{"children":"What is a sealed class and why use one?"}]] a4:[["$","p","p-0",{"children":["A class or interface that lists exactly which classes may extend it with ",["$","code","code-0",{"children":"permits"}],". It models a closed set of cases, and lets the compiler check that a switch handles every one."]}]] a5:[["$","p","p-0",{"children":"What is the difference between a sealed interface and an enum?"}]] a6:[["$","p","p-0",{"children":["An enum is a fixed set of instances that all share the same fields. A sealed interface is a fixed set of types, and each type can carry its own different data, like ",["$","code","code-0",{"children":"Success"}]," with a transaction id and ",["$","code","code-1",{"children":"Failed"}]," with a reason."]}]] a7:[["$","p","p-0",{"children":["Why avoid ",["$","code","code-0",{"children":"default"}]," when switching over a sealed type?"]}]] a8:[["$","p","p-0",{"children":["Without ",["$","code","code-0",{"children":"default"}],", the compiler checks every permitted subtype is handled, so adding a new subtype breaks the build where it needs attention. A ",["$","code","code-1",{"children":"default"}]," hides the new case and it fails quietly at runtime."]}]] a9:[["$","p","p-0",{"children":["When does ",["$","code","code-0",{"children":"var"}]," hurt readability?"]}]] aa:[["$","p","p-0",{"children":["When the type is not obvious from the right side, like ",["$","code","code-0",{"children":"var result = service.process(order)"}],". It also has traps, such as ",["$","code","code-1",{"children":"var list = new ArrayList<>()"}]," giving ",["$","code","code-2",{"children":"ArrayList