| Encapsulation | Bundling data and methods; hiding internal state via access control |
| private | Accessible only within the declaring class |
| default (package-private) | Accessible within the same package only |
| protected | Accessible within package + subclasses (even in other packages) |
| public | Accessible from anywhere |
| Immutable Class | final class, final fields, no setters, defensive copy in constructor/getters |
| Record (Java 16+) | Compact immutable data carrier; auto-generates constructor, accessors, equals, hashCode, toString |
| JavaBeans Convention | private fields + public getXxx()/setXxx() + no-arg constructor |
| Effectively Final | Variable not declared final but never reassigned after initialization |
| JPMS Module (Java 9+) | Module-level encapsulation via exports/opens in module-info.java |
| Modifier | Same Class | Same Package | Subclass | World |
|---|---|---|---|---|
| private | ✓ | ✗ | ✗ | ✗ |
| default | ✓ | ✓ | ✗ | ✗ |
| protected | ✓ | ✓ | ✓ | ✗ |
| public | ✓ | ✓ | ✓ | ✓ |
Java Encapsulation & Access Modifiers Interview Questions & Answers
Q1. What is encapsulation in Java?
A: Encapsulation is one of the four fundamental OOP principles. It is the practice of bundling data (fields) and the methods that operate on that data into a single unit (a class), while restricting direct access to the internal state from outside the class. Encapsulation is achieved by declaring fields as private and exposing them through public getter and setter methods. This ensures controlled access, validation, and the ability to change the internal implementation without affecting client code.
Q2. What are the four access modifiers in Java?
A: Java provides four access modifiers: private (accessible only within the same class), default/package-private (no keyword; accessible within the same package), protected (accessible within the same package and by subclasses in other packages), and public (accessible from everywhere). Note that private and public can be applied to class members; public and default can be applied to top-level classes.
Q3. What is the difference between private and default access?
A: A private member is accessible only within the class it is declared in — not even by other classes in the same package. A default (package-private) member is accessible by any class within the same package, but not by classes outside the package. Default access is used when you want package-level collaboration without exposing internals to the entire world.
Q4. What is protected access and how does it differ from public?
A: A protected member is accessible within the same package (like default) and also by subclasses that reside in different packages. However, the subclass access is only through the subclass reference — not through a superclass reference. A public member is accessible from any class anywhere in any package without restriction. The key distinction: protected restricts world access but allows inheritance-based access across packages.
Q5. Can a top-level class be declared private or protected?
A: No. A top-level class (a class not nested inside another class) can only be declared public or default (package-private). Declaring a top-level class as private or protected is a compile-time error. Inner (nested) classes, however, can use all four access modifiers.
Q6. What are the benefits of encapsulation?
A: The key benefits are: (1) Data hiding — internal state is not directly accessible; (2) Controlled access — validation logic can be placed in setters; (3) Flexibility — internal implementation can change without breaking the public API; (4) Maintainability — reduces coupling between components; (5) Security — prevents unauthorized or inconsistent state changes; (6) Testability — well-encapsulated classes are easier to unit test in isolation.
Q7. What is the JavaBeans convention?
A: The JavaBeans convention specifies that a reusable Java component (bean) must: (1) have a public no-argument constructor; (2) declare all fields as private; (3) provide public getter methods named getFieldName() (or isFieldName() for booleans); (4) provide public setter methods named setFieldName(value); (5) implement Serializable (optional but conventional). Many frameworks (Spring, JSF, JPA) rely on this convention for dependency injection and property binding.
public class Employee implements java.io.Serializable {
private String name;
private int age;
private boolean active;
public Employee() {} // no-arg constructor
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public int getAge() { return age; }
public void setAge(int age) {
if (age < 0) throw new IllegalArgumentException("Age cannot be negative");
this.age = age;
}
public boolean isActive() { return active; } // boolean uses "is"
public void setActive(boolean active) { this.active = active; }
}Q8. What is the difference between encapsulation and information hiding?
A: Encapsulation is the mechanism of bundling data and methods together in a class. Information hiding is a design principle that says the internal details of a module should not be visible to its clients. Encapsulation is the primary Java mechanism used to achieve information hiding. In other words, information hiding is the goal; encapsulation is the tool. You can have encapsulation without full information hiding (e.g., public fields in a class are encapsulated by the class structure but nothing is hidden).
Q9. What is an immutable class and how do you create one?
A: An immutable class is a class whose instances cannot be modified after creation. To create an immutable class: (1) declare the class as final (prevents subclassing); (2) declare all fields as private final; (3) initialize all fields in the constructor; (4) do not provide setter methods; (5) perform defensive copying in the constructor for mutable fields; (6) return defensive copies from getters for mutable fields.
public final class ImmutablePerson {
private final String name;
private final int age;
private final List<String> hobbies;
public ImmutablePerson(String name, int age, List<String> hobbies) {
this.name = name;
this.age = age;
// Defensive copy of mutable parameter
this.hobbies = List.copyOf(hobbies);
}
public String getName() { return name; }
public int getAge() { return age; }
// Return defensive copy so caller cannot mutate internal list
public List<String> getHobbies() {
return Collections.unmodifiableList(hobbies);
}
}Q10. Why is String immutable in Java?
A: String is immutable for several reasons: (1) String pool — multiple references can safely point to the same literal without one reference mutating it; (2) Thread safety — immutable objects are inherently thread-safe without synchronization; (3) Security — class names used in class loading, network hostnames, and file paths should not change; (4) Caching — hashCode is cached on first computation since the string never changes; (5) Performance — compiler and JVM can optimize string operations. String achieves immutability by being a final class with a private final char[] (or byte[] in Java 9+) and no mutating methods.
Q11. What are the benefits of immutability in concurrent code?
A: Immutable objects provide the following concurrency benefits: (1) Thread safety without synchronization — since state cannot change after construction, no locking is needed; (2) No visibility problems — once published safely (via final field), all threads see a consistent state; (3) Safe sharing — can be freely shared across threads without copying; (4) No race conditions — race conditions require a shared mutable state; (5) Simplifies reasoning — eliminates an entire class of concurrency bugs. The Java Memory Model guarantees that a final field's value is visible to all threads after the constructor finishes, without any additional synchronization.
Q12. What is a record class in Java 16+?
A: A record is a special kind of class introduced as a standard feature in Java 16 (previewed in Java 14/15). It is a compact, immutable data carrier. Declaring record Point(int x, int y) {} automatically generates: a canonical constructor, private final fields x and y, public accessor methods x() and y() (not getX/getY), equals(), hashCode(), and toString(). Records are implicitly final and cannot extend other classes.
// Record declaration
public record Point(int x, int y) {}
// Usage
Point p = new Point(3, 4);
System.out.println(p.x()); // 3 (accessor, not getX())
System.out.println(p.y()); // 4
System.out.println(p); // Point[x=3, y=4]
// Custom compact constructor with validation
public record Range(int min, int max) {
public Range { // compact constructor
if (min > max) throw new IllegalArgumentException("min > max");
}
}
// Records can implement interfaces
public record ColoredPoint(int x, int y, String color) implements Printable {
public void print() {
System.out.println("Point(" + x + "," + y + ") color=" + color);
}
}Q13. How does the Java Module System (JPMS, Java 9+) enhance encapsulation?
A: Before JPMS, any public class was accessible from anywhere on the classpath — packages offered no real boundary. The module system adds a higher level of encapsulation: a module explicitly declares which packages it exports in module-info.java. Packages not exported are completely inaccessible to code in other modules, even if the classes inside are public. This is called strong encapsulation. The opens directive allows reflective access without compile-time access, used by frameworks like Spring and Hibernate.
// module-info.java
module com.example.myapp {
exports com.example.myapp.api; // public API
// com.example.myapp.internal is NOT exported = strongly encapsulated
opens com.example.myapp.model to com.fasterxml.jackson.databind; // reflective access
requires java.sql;
requires com.google.guava;
}Q14. What is package-private access and when should you use it?
A: Package-private (default) access means no access modifier keyword is written. The member or class is accessible only to code within the same package. It is ideal for: (1) helper classes that support a public API but should not be used directly by clients; (2) utility methods shared among classes within a module/package; (3) test-scoped visibility — test classes in the same package can access package-private members without making them public. Many well-designed libraries use package-private extensively to keep their public API surface small.
Q15. Can an inner class access private members of its outer class?
A: Yes. A non-static inner class (member inner class) has unrestricted access to all members of its enclosing outer class, including private fields and methods. The Java compiler achieves this by generating synthetic accessor methods when needed. This is a deliberate design choice that allows inner classes to act as "trusted helpers" of the outer class without the outer class having to widen its access modifiers.
Q16. What is the difference between a static nested class and an inner class regarding access?
A: A static nested class does not hold a reference to an enclosing instance. It can only access the static members of the outer class directly; to access instance members, it needs an explicit outer class reference. A non-static inner class holds an implicit reference to the enclosing outer instance and can directly access all instance and static members (including private ones) of the outer class. Inner classes can cause memory leaks if they outlive the outer instance.
| Aspect | Static Nested Class | Non-static Inner Class |
|---|---|---|
| Outer instance ref | None | Implicit (OuterClass.this) |
| Access outer static | Yes (directly) | Yes |
| Access outer instance | Only via reference | Yes (directly) |
| Can declare static members | Yes | No (except constants) |
| Memory leak risk | Low | Higher |
| Instantiation | OuterClass.Nested n = new OuterClass.Nested() | outer.new Inner() |
Q17. What is a local variable captured by a lambda, and what does "effectively final" mean?
A: A lambda expression can capture local variables from the enclosing scope, but only if those variables are final or effectively final. A variable is effectively final if it is never reassigned after its initial assignment — the compiler treats it as if it were declared with the final keyword. This restriction exists because lambdas may execute in a different thread or at a later time; if the variable were mutable, there would be no safe way to capture its value without extra synchronization. Instance fields and static fields do not have this restriction.
Q18. How do anonymous classes access outer class members and local variables?
A: Anonymous classes, like non-static inner classes, hold an implicit reference to the enclosing instance and can access all its members (including private ones). However, local variables accessed inside an anonymous class must be effectively final, just like lambdas. Anonymous classes can also access the effectively-final parameters of the enclosing method. One difference from lambdas: anonymous classes have their own this (referring to the anonymous class instance), whereas lambdas share this with the enclosing class.
Q19. What is the private constructor pattern and when is it used?
A: A private constructor prevents a class from being instantiated from outside. It is used in: (1) Singleton pattern — only one instance is created internally; (2) Utility/helper classes — classes with only static methods (like java.lang.Math, java.util.Collections) should not be instantiated; (3) Factory method pattern — construction is controlled through static factory methods; (4) Builder pattern — the product class may have a private constructor with the builder as a nested class; (5) Enum emulation — before enums, constants were implemented via private constructors.
// Utility class pattern
public final class MathUtils {
private MathUtils() {
throw new UnsupportedOperationException("Utility class");
}
public static int square(int n) { return n * n; }
}
// Singleton with private constructor
public final class ConfigManager {
private static final ConfigManager INSTANCE = new ConfigManager();
private final Properties props;
private ConfigManager() {
props = new Properties();
// load properties
}
public static ConfigManager getInstance() { return INSTANCE; }
public String get(String key) { return props.getProperty(key); }
}Q20. What is the Builder pattern and how does it relate to encapsulation?
A: The Builder pattern is used to construct complex objects step by step, especially when the object has many optional parameters. It enhances encapsulation by: (1) keeping the target class's constructor private (only the builder can call it); (2) exposing a fluent builder API instead of a telescoping constructor; (3) the target class remains immutable — the builder accumulates state and constructs the final object once. Joshua Bloch's effective Java recommends builders when a class has 4+ parameters, especially optional ones.
Q21. What is the var keyword in Java and does it affect encapsulation?
A: var (introduced in Java 10) enables local variable type inference — the compiler infers the type from the right-hand side expression. It does not affect encapsulation because: (1) var is only usable for local variables, never for fields or method parameters; (2) the inferred type is still statically typed at compile time; (3) access modifiers (which control encapsulation) are not applicable to local variables. A subtlety: var can accidentally expose a more specific type than intended (e.g., an implementation class rather than an interface), which can weaken encapsulation if the variable type leaks into the API.
Q22. Can protected members be accessed by a subclass in a different package through a superclass reference?
A: No. A subclass in a different package can access a protected member only through a reference of the subclass type (or a more specific subtype), not through a reference of the superclass or another subclass. This is a subtle but important restriction. For example, if class B in package2 extends class A in package1, and A has a protected method foo(), then within B, you can call this.foo() or super.foo(), but you cannot call ((A) someObject).foo() if someObject is not an instance of B.
Q23. What is defensive copying and why is it important for encapsulation?
A: Defensive copying means creating a copy of a mutable object when receiving it (in a constructor or setter) or returning it (from a getter), so the caller cannot manipulate the internal state through the original reference. Without defensive copying, even a private final field holding a mutable reference (like a Date or List) can be mutated externally, breaking encapsulation. The copy should be made before validation to prevent a time-of-check/time-of-use (TOCTOU) attack (always copy first, then validate).
Q24. How does encapsulation support the Open/Closed Principle?
A: The Open/Closed Principle (OCP) states that a class should be open for extension but closed for modification. Encapsulation supports OCP by hiding implementation details behind a stable public interface. When internals are private, the implementation can change (optimization, bug fix, algorithm replacement) without changing the public API, so existing client code does not break. This means the class is "closed" for modification from the client's perspective but "open" for internal evolution.
Q25. What are getter/setter best practices?
A: Best practices include: (1) only provide setters when the field truly needs to be mutable — prefer immutability; (2) add validation logic in setters rather than allowing any value; (3) return copies of mutable objects from getters; (4) for boolean, use isXxx() naming; (5) avoid exposing internal collections directly — return unmodifiable views; (6) consider returning Optional from getters for nullable fields; (7) do not call overridable methods from constructors; (8) in multi-threaded code, make getter/setter pairs synchronized or use volatile fields.
Q26. What happens if you inherit a class and try to reduce the visibility of an overriding method?
A: You cannot reduce the visibility of an overriding method. Java's Liskov Substitution Principle (LSP) requires that a subclass object must be usable anywhere a superclass reference is expected. If the overriding method had narrower access, callers using the superclass reference would get unexpected access errors. Therefore, overriding methods can maintain or widen access, but never narrow it. Trying to override a public method with a protected or private method results in a compile-time error.
Q27. What is the difference between encapsulation and abstraction?
A: Abstraction is about hiding complexity by showing only the essential features of an object (the "what"). It focuses on the design level and is achieved through interfaces and abstract classes. Encapsulation is about hiding implementation details and protecting internal state (the "how"). It focuses on the implementation level and is achieved through access modifiers. Example: an interface abstracts "what a Stack does (push, pop, peek)"; a class encapsulates "how the Stack does it (using an internal array or linked list with private fields)."
Q28. Can you make a class final but not its fields? What is the effect?
A: Yes. Making a class final prevents subclassing but does not make fields immutable. The fields remain mutable (unless also declared final). Making the class final alone prevents someone from bypassing your encapsulation by subclassing and overriding methods. For full immutability, you need final class + private final fields + no setters + defensive copies. Making a class final without final fields gives you "non-extensible" but not "immutable."
Q29. What is the significance of the final keyword on a field vs on a local variable?
A: On an instance field, final means the field must be assigned exactly once — either at declaration or in the constructor — and can never be reassigned. The Java Memory Model guarantees safe publication of final fields to other threads after the constructor completes. On a local variable, final means the variable cannot be reassigned after initialization, which is the requirement for capturing it in a lambda or anonymous class. Note: for reference types, final only prevents reassignment of the reference — it does not make the object itself immutable.
Q30. How does Spring Framework use encapsulation and access modifiers?
A: Spring uses reflection to inject dependencies, so it can set private fields directly (via field injection with @Autowired). However, Spring recommends constructor injection over field injection precisely because constructor injection works within normal Java encapsulation rules (no reflection needed for basic use) and makes dependencies explicit and final. Spring also respects the JavaBeans convention for property binding in @ConfigurationProperties. In the module system, Spring modules use opens to allow Spring's reflection-based injection even in JPMS projects.
Q31. What is the "principle of least privilege" and how does it apply to access modifiers?
A: The principle of least privilege states that every component should have access to only what it needs to perform its function, and no more. In Java, this means: start with private and only widen access when necessary. A field should be private unless there is a strong reason to widen it. A method should be private unless it needs to be called externally. This reduces the API surface, makes the class easier to reason about, reduces the chance of misuse, and gives you more freedom to change the implementation later.
Q32. What are sealed classes (Java 17) and how do they relate to encapsulation?
A: Sealed classes (Java 17 stable) restrict which classes can extend them. By declaring public sealed class Shape permits Circle, Rectangle, Triangle, only the three listed classes can be subtypes. This is a form of controlled extensibility that enhances encapsulation at the type hierarchy level: the maintainer decides exactly which subtypes exist. Combined with pattern matching in switch expressions, sealed classes allow exhaustive checks without open-ended inheritance that could bypass the class's invariants.
Q33. Explain the concept of mutable vs immutable objects in collections.
A: When a class holds a collection field, encapsulation requires care: (1) if the constructor accepts a List, make a defensive copy so the caller cannot later mutate the field via their reference; (2) if a getter returns the internal list, wrap it in Collections.unmodifiableList() or return a copy; (3) prefer List.copyOf() (Java 10+) which returns an unmodifiable list snapshot. Failing to do this means callers can reach into your private state through the collection reference, violating encapsulation even though the field is private.
Q34. What is the purpose of making a constructor private in a class hierarchy (abstract class pattern)?
A: Sometimes the base class has a private constructor to enforce that instances are only created through a specific factory or through a limited set of subtypes (like sealed classes). This is also used in the "abstract base with controlled subclasses" pattern where the class itself is not abstract but restricts subclassing by making the constructor package-private or private. This prevents external subclassing while allowing internal subclasses in the same file or package.
Q35. How does encapsulation differ between Java and Kotlin?
A: Kotlin defaults to public visibility (like Java) but adds a internal modifier (visible within the same compilation module — similar to Java 9 module exports). Kotlin properties automatically generate backing fields with getters/setters following JavaBeans convention but with a cleaner syntax. Kotlin's data class is similar to Java's record but mutable by default (val vs var). Java's encapsulation requires explicit access modifiers on each field; Kotlin's constructor properties are automatically private fields with generated accessors.
Q36. What happens when a subclass tries to access a private member of the parent class through inheritance?
A: Private members are not inherited. A subclass does not inherit private fields or methods from the parent class — they exist in the parent but are inaccessible directly to the subclass. The subclass can only access them through protected or public getter/setter methods defined in the parent. The JVM does store the parent's private fields in the subclass object's memory, but the language-level access restriction means the subclass code cannot name them directly.
Q37. What are nested enums and what access rules apply to them?
A: A nested enum inside a class is implicitly static. It can have access modifiers just like static nested classes: private, package-private, protected, or public. A nested enum can access the outer class's static members. Like all enums, the enum's constructor is implicitly private, so no external instantiation is possible. Nested enums are a good encapsulation tool when the enum's meaning is tightly coupled to the enclosing class and should not be exposed independently.
Q38. How does the transient keyword interact with encapsulation?
A: The transient modifier tells the Java serialization mechanism to skip a field during serialization. It is often used on sensitive private fields (passwords, encryption keys, cached computed values) to ensure they are not persisted or transmitted. This complements encapsulation: even if someone serializes and deserializes an object, sensitive state is not exposed through the serialized form. After deserialization, transient fields have their default values (? for char, 0 for int, null for references).
Q39. What is the volatile keyword and how does it relate to encapsulation?
A: volatile guarantees visibility of field writes across threads — a write to a volatile field is visible to all threads that subsequently read it, without caching in CPU registers. It does not provide atomicity for compound operations. While not strictly an encapsulation mechanism, it is often used on private fields that are shared between threads to ensure correctness. Without volatile (or synchronization), a private field could be stale in another thread's cache, which is a kind of "invisible mutation" problem.
Q40. What is the difference between a record and a regular immutable class?
A: A record automatically generates the canonical constructor, accessors (named after the component, not getXxx), equals(), hashCode(), and toString(). Records are always final and cannot extend other classes. A regular immutable class requires you to write all these methods manually, but offers more flexibility: you can choose getter naming, implement custom equals logic, extend another class (immutable or not), and add mutable state if needed. Records are ideal for simple value types (DTOs, coordinates, range objects); regular immutable classes are better for complex domain objects.
Q41. How do you make a copy constructor work correctly with encapsulation?
A: A copy constructor creates a new object with the same state as an existing object. For proper encapsulation: (1) access the source object's private fields directly (since it's the same class, this is allowed); (2) perform deep copies of mutable reference fields, not just copying references; (3) do not call getters in the copy constructor since they might return defensive copies or trigger side effects; (4) the copy constructor is preferred over Cloneable/clone() which has many design flaws in Java.
Q42. What are compile-time vs runtime access checks in Java?
A: Java enforces access modifier rules at compile time. If your code tries to access a private member from outside the class, the compiler rejects it. At runtime, the JVM also enforces access via the AccessController, but reflection can bypass compile-time checks using field.setAccessible(true). JPMS (Java 9+) adds stronger runtime enforcement — even with reflection, accessing unexported module internals throws InaccessibleObjectException unless the module opens the package. The module system thus provides true runtime enforcement, not just compile-time.
Q43. Can you change the access modifier of a field in a subclass?
A: Fields in Java are not overridden, they are hidden. If a subclass declares a field with the same name as a superclass field, the subclass field shadows (hides) the superclass field. You can change the access modifier of the subclass field independently. However, this is generally bad practice as it leads to confusion about which field is accessed. When using a superclass reference, the superclass field is accessed; when using a subclass reference, the subclass field is accessed — this is field hiding, not polymorphism.
Q44. What is the package structure best practice for encapsulation?
A: A well-designed package structure uses packages as encapsulation boundaries: (1) place closely related classes in the same package so they can use package-private access; (2) expose only the public API classes (interfaces, factories); (3) use sub-packages like com.example.mylib.internal or com.example.mylib.impl to signal internal classes (convention only — access control requires JPMS for hard enforcement); (4) with JPMS, only export the api package and keep internal packages unexported for strong encapsulation.
Q45. How do you prevent subclassing without using the final keyword?
A: Alternatives to final for preventing subclassing: (1) make all constructors package-private — classes outside the package cannot subclass because they cannot call a constructor; (2) use sealed classes (Java 17) which explicitly enumerate permitted subclasses; (3) use a private constructor with static factory methods — no subclass can call super(); (4) make the class an enum (implicitly final). Each approach has trade-offs in terms of flexibility and expressiveness.
Q46. What is "deep encapsulation" vs "shallow encapsulation"?
A: Shallow encapsulation makes fields private but returns direct references to mutable objects — the class is technically encapsulated but the internal state can still be mutated through those references. Deep encapsulation ensures that no mutable internal state can be reached from outside: all mutable fields use defensive copies, returned collections are unmodifiable, and nested mutable objects are also encapsulated. Deep encapsulation is harder to achieve but provides stronger invariant guarantees.
Q47. How does record's compact constructor differ from a regular constructor?
A: In a record, the compact constructor omits the parameter list (it implicitly has the same parameters as the canonical constructor). Within the compact constructor, you can validate and transform the component values — they are automatically assigned to the fields after the compact constructor body executes. You cannot explicitly assign to the record's fields inside a compact constructor; the assignment happens automatically. A regular constructor in a record must explicitly assign all fields and is written with the full parameter list.
Q48. What is the role of encapsulation in the Singleton design pattern?
A: Encapsulation is central to Singleton: the constructor is private to prevent external instantiation, the sole instance is held in a private static field, and it is exposed through a public static factory method. Without private access, the single-instance invariant cannot be maintained. The enum-based Singleton (Josh Bloch's preferred approach) leverages the JVM's guarantee that enum instances are created exactly once, providing Singleton semantics without any custom code.
Q49. What is the difference between public API and internal API in terms of encapsulation?
A: A public API is the set of types and methods intentionally exposed to clients — documented, stable, and subject to backward compatibility guarantees. An internal API is implementation detail — subject to change without notice and not meant for external use. Java's access modifiers help enforce this distinction but only at the package level. JPMS enforces it at the module level. Annotations like @Internal (from frameworks) or @VisibleForTesting (from Guava) document intent but do not enforce access. Clear separation of public and internal APIs is a hallmark of good library design.
Q50. What is the @VisibleForTesting annotation and how does it relate to encapsulation?
A: @VisibleForTesting (from Google Guava or similar libraries) is a documentation annotation placed on methods or fields that have a wider access modifier than necessary — purely to allow unit testing. For example, a package-private method instead of private, so the test class in the same package can call it. It signals "this is not public API; the wider access is only for testing." It is a pragmatic compromise between strict encapsulation and testability, used when the alternative (reflection or redesign) is worse.
Q51. How does encapsulation interact with serialization?
A: Java serialization can bypass encapsulation by directly reading and writing private fields without going through getters/setters. This means an object with private fields can be serialized and deserialized even without public setters. To control what gets serialized: (1) use transient to exclude sensitive fields; (2) implement writeObject() / readObject() for custom serialization logic; (3) implement readResolve() to maintain Singleton invariants after deserialization; (4) consider using JSON/protobuf serialization (Jackson, etc.) which do respect access via getters.
Q52. What is the difference between field access and method access in terms of OOP?
A: Accessing fields directly (even via a reference) is resolved statically at compile time based on the reference type — no polymorphism. Method access is resolved dynamically at runtime based on the actual object type (virtual dispatch for non-final, non-static, non-private methods). Making fields private and providing methods enforces polymorphism: subclasses can override the method to change behavior, but a field cannot be "overridden." This is another reason why fields should be private — you preserve the option for polymorphic behavior through methods.
Q53. How does a local class differ from an anonymous class in terms of encapsulation?
A: Both local classes and anonymous classes are defined within a method and can access the enclosing instance members and effectively final local variables. The difference: a local class has a name and can be instantiated multiple times within the method; an anonymous class has no name and is instantiated exactly once at the point of declaration. Neither can be accessed from outside the method, making them the most encapsulated class types in Java. Local classes can have constructors; anonymous classes cannot (their "constructor" is synthesized).
Q54. What is the "exports ... to" directive in JPMS?
A: The qualified exports directive exports com.example.api to com.example.client limits which modules can access an exported package. Unlike unqualified exports (which any module can read), qualified exports restrict access to a specific set of named modules. This is useful for frameworks that need access to internal APIs without making them broadly available. It is a fine-grained encapsulation tool at the module level, providing more precise control than the package-level access modifiers.
Q55. What is a degenerate accessor (getter) and why is it a bad practice?
A: A degenerate accessor simply returns the private field reference without any additional logic or defensive copy. For primitive types and immutable objects (String, Integer), this is fine. For mutable objects (Date, List, arrays), returning the raw reference exposes the internal state — callers can mutate the object behind the class's back. This is sometimes called "aliasing." The fix is to return a defensive copy or an unmodifiable view. Arrays are particularly dangerous: always return a copy of an array, never the array itself.
Q56. What is method chaining in the context of the Builder pattern?
A: Method chaining (fluent interface) in builders means each setter-like method returns this (the builder instance), allowing calls to be chained: new Builder().name("Alice").age(30).email("a@b.com").build(). This pattern keeps the product class immutable (built in a single build() call with all required values), avoids telescoping constructors, and makes code readable. The builder accumulates mutable state; the product is immutable. The builder is often a public static nested class of the product.
public final class Person {
private final String name;
private final int age;
private final String email;
private Person(Builder b) {
this.name = b.name;
this.age = b.age;
this.email = b.email;
}
public String getName() { return name; }
public int getAge() { return age; }
public String getEmail() { return email; }
public static class Builder {
private String name;
private int age;
private String email;
public Builder name(String name) { this.name = name; return this; }
public Builder age(int age) { this.age = age; return this; }
public Builder email(String email) { this.email = email; return this; }
public Person build() {
if (name == null) throw new IllegalStateException("name required");
return new Person(this);
}
}
}
// Usage
Person p = new Person.Builder()
.name("Alice")
.age(30)
.email("alice@example.com")
.build();Q57. Why can't a static method access instance (non-static) members of a class?
A: Static methods belong to the class, not to any instance. They execute without a this reference — there is no instance whose fields they could access. Instance fields and methods require an object to operate on. From an encapsulation standpoint, static methods can still access private static fields and other private static methods of the same class. They can also access private instance members if given an explicit instance reference, since access control is class-based, not instance-based.
Q58. How do you implement a thread-safe Singleton with lazy initialization?
A: The best approach is the initialization-on-demand holder idiom (also called Bill Pugh Singleton). It uses a private static nested class whose class loading is deferred until first use. The JVM guarantees class initialization is thread-safe, so no explicit synchronization is needed.
public final class LazyDatabase {
private final String url;
private LazyDatabase() {
this.url = System.getProperty("db.url");
}
// Holder class is loaded only when getInstance() is first called
private static class Holder {
static final LazyDatabase INSTANCE = new LazyDatabase();
}
public static LazyDatabase getInstance() {
return Holder.INSTANCE;
}
public String getUrl() { return url; }
}
// OR use enum (simpler, also handles serialization correctly)
public enum EnumSingleton {
INSTANCE;
public void doWork() { /* ... */ }
}Q59. What is the difference between interface default methods and abstract class methods in the context of encapsulation?
A: Interface default methods (Java 8+) must be public — you cannot add private or package-private default methods (except private interface methods added in Java 9). Abstract class methods can have any access modifier. Abstract classes can have private fields and private methods, providing true encapsulation of shared state. Interfaces cannot have instance state (only static final constants), so encapsulation of mutable state is impossible in interfaces. Abstract classes are the right choice when you need to share private implementation and mutable state among subclasses.
Q60. What are private interface methods (Java 9) and why were they added?
A: Java 9 added private methods to interfaces to reduce code duplication among default and static interface methods. Before Java 9, if two default methods shared logic, there was no way to extract a helper — you had to duplicate the code or make it public (which exposes unnecessary API). Private interface methods can be called by default methods and other private methods in the same interface but are not inherited by implementing classes. This is a small but meaningful encapsulation improvement for interface design.
Q61. What is the this() constructor call and how does it relate to encapsulation?
A: this() is a constructor delegation call — one constructor calls another constructor in the same class. It is always the first statement in a constructor body. This pattern centralizes initialization logic in one "master" constructor (typically the one with the most parameters), and other constructors delegate to it with default values. This maintains encapsulation by ensuring all initialization (including field validation) happens in one controlled place, preventing inconsistent object state.
Q62. How does encapsulation relate to the DRY (Don't Repeat Yourself) principle?
A: Encapsulation supports DRY by centralizing the business logic for accessing or modifying a field in one place (the getter/setter or the class's methods). Instead of scattering field access logic throughout the codebase, all code goes through the class's interface. When the validation rule or computation changes, you update it in one method, not in a hundred places. This is why exposing fields directly (public fields) violates DRY — validation logic must be repeated at every access site.
Q63. What is the risk of using public static fields?
A: Public static mutable fields are global mutable state — the worst kind of state in software. Any code anywhere can read or write them, making it impossible to reason about correctness, especially in multi-threaded code. They break encapsulation entirely and make testing extremely difficult (tests can interfere with each other through shared global state). The only acceptable public static fields are constants: public static final with an immutable type (primitive or String or an immutable class). Even then, if the type is mutable, the final reference does not help.
Q64. What is the difference between module "exports" and "opens" in Java 9+?
A: exports allows compile-time and runtime access to public types in the exported package for code in other modules. Reflection against private members is still blocked. opens allows reflective access (including private members) at runtime but does not grant compile-time access. Frameworks like Spring, Jackson, and Hibernate need opens to do dependency injection and serialization via reflection. exports ... to and opens ... to are qualified versions that restrict which modules benefit.
Q65. How is encapsulation tested? Can you test private methods?
A: Encapsulation means private methods should be tested indirectly through the public API that uses them. If a private method is so complex that it needs its own test, it is a sign the method should be extracted into a separate class with package-private or public visibility. Alternatives for testing private members: (1) use package-private methods annotated with @VisibleForTesting and place tests in the same package; (2) use reflection (Method.setAccessible(true)) — fragile and couples tests to implementation; (3) use subclassing (limited by final classes). Generally, testing private methods directly is an antipattern.
Q66. What is method hiding vs method overriding?
A: Method overriding applies to instance methods: when a subclass provides a method with the same signature as a superclass instance method, the subclass version is called at runtime based on the actual object type (polymorphism). Method hiding applies to static methods: when a subclass declares a static method with the same signature as a superclass static method, the subclass method hides the parent's. Static method resolution is based on the reference type, not the object type, so no polymorphism occurs. Access modifiers on the hiding method follow the same widening rule as overriding.
Q67. What is the difference between composition and inheritance in the context of encapsulation?
A: Inheritance can break encapsulation of the parent class because: (1) subclasses are tightly coupled to the parent's implementation; (2) overriding one method may inadvertently affect other methods that call it (the "fragile base class" problem). Composition ("has-a") is better for encapsulation: the containing class holds a reference to the component and delegates; the component's internals remain fully hidden. Joshua Bloch's "favor composition over inheritance" guideline is partly motivated by encapsulation concerns.
Q68. What is a value object and how does it relate to immutability?
A: A value object is an object whose identity is defined by its value, not by its reference. Two value objects with the same values are equal regardless of whether they are the same instance. Value objects should be immutable — if their state could change, equality would become unreliable and caching would be broken. Java's record type is designed specifically for value objects. Examples: LocalDate, BigDecimal, Money, Point. Project Valhalla aims to add "primitive classes" (value types) to the JVM for performance benefits of value semantics.
Q69. What happens when you access a superclass's protected method through an unrelated subclass reference?
A: This is the nuanced protected access rule. If class C in package2 extends class A in package1 (which has a protected method), within C you can call the protected method on this or on any instance of C (or subtype of C). But if D also extends A in another package, you cannot call A's protected method on a D reference from within C — even though D is also a valid subtype of A. The protected access is restricted to "through a reference of C or its subtypes" within C's code.
Q70. How do records interact with the Java Module System?
A: Records are regular classes from the module system's perspective. A record defined in an unexported package is inaccessible to code in other modules, just like any other class. A record in an exported package is accessible. Records implement java.lang.Record (the abstract base class) which is in the java.base module. Reflection on record components (via Class.getRecordComponents()) respects module access — the package must be opened for reflective access to the component values if the record is not in an exported package.
Q71. What is the "fragile base class" problem?
A: The fragile base class problem occurs when a superclass changes its internal implementation in a way that breaks subclasses that depended on the old behavior. This happens when subclasses override methods that call each other, and the superclass changes which methods call which. The problem is a consequence of implementation inheritance breaking encapsulation: the subclass author needs to know the internal calling structure of the superclass. Solutions: prefer composition; document and carefully design for extension (using template method pattern); or make the class final.
Q72. What is the difference between String.intern() and the String pool from an encapsulation standpoint?
A: The String pool is an internal JVM implementation detail of the String class — clients cannot directly manipulate it. String.intern() is the only public way to interact with it. This is encapsulation: the pool's data structure (hash table in native code) is hidden; clients see only the effect (same reference for equal strings). String's immutability is what makes the pool safe — if strings were mutable, two variables sharing the same pooled string would interfere with each other.
Q73. What is the impact of encapsulation on API evolution and backward compatibility?
A: Strong encapsulation (making fields private, exposing minimal public API) gives library authors freedom to evolve. Changes to private implementation do not break clients. Adding new private fields, changing field types, reordering fields in the constructor — all are safe changes. However, changing a public method signature, removing a public method, or changing the behavior of a public method breaks backward compatibility. This is why Java's JDK team marks experimental APIs as @jdk.internal.* (strongly encapsulated) to reserve the right to change them.
Q74. How does the @Immutable annotation (thread-safe annotations from JCIP) relate to encapsulation?
A: The @Immutable annotation from the Java Concurrency in Practice (JCIP) annotations library is a documentation annotation that declares a class to be immutable and therefore thread-safe. It does not enforce immutability at compile time (no compiler check). It signals to readers and tools that the class is designed to have no mutable state. Similarly, @ThreadSafe and @NotThreadSafe document thread-safety guarantees. They supplement encapsulation by making design intent explicit.
Q75. What is an Optional and how does it relate to encapsulation of nullable values?
A: Optional<T> (Java 8+) is a container type that explicitly represents a value that may or may not be present, replacing null returns. From an encapsulation standpoint, returning Optional from a getter encapsulates the "presence or absence" semantics: callers must explicitly handle both cases via isPresent(), orElse(), ifPresent(), etc. This prevents NullPointerExceptions and makes the API's intent clear. However, Optional should not be used for method parameters or fields — only for return types where absence is a meaningful and common case.
Q76. What is the difference between a shallow copy and a deep copy in the context of encapsulation?
A: A shallow copy creates a new object whose fields are copies of the original's field values. For primitive fields, this is a true copy. For reference fields, the copy shares the same referenced objects as the original — mutations to those objects affect both the copy and the original, breaking encapsulation. A deep copy creates new objects for all reachable mutable objects, creating a fully independent copy. For encapsulation, deep copies are often needed in defensive copying scenarios to prevent clients from mutating nested mutable state.
Q77. What is the difference between encapsulation in Java and C++?
A: In C++, access control works at the class level (like Java) but C++ also has the friend keyword which allows specific classes or functions to access private members — effectively a white-listed encapsulation bypass. Java has no friend equivalent; inner classes access outer class privates via compiler-generated synthetic accessors. C++ also has public, protected, and private inheritance which affects how base class access modifiers are inherited — Java has no such concept (all Java inheritance is like C++ public inheritance). Java's encapsulation is simpler and stricter.
Q78. What is a "leaky abstraction" in the context of encapsulation?
A: A leaky abstraction is when the internal implementation details "leak" through the public interface, forcing clients to know about and depend on those details. Examples: returning an ArrayList instead of a List (exposes implementation); a method's behavior changing based on whether it's called for the first time (exposes lazy initialization); throwing implementation-specific exceptions (exposes internal libraries). Encapsulation aims to prevent leaky abstractions by keeping the public API decoupled from internal choices.
Q79. What is an access control context and how does the SecurityManager relate?
A: The Java SecurityManager (deprecated in Java 17, removed in Java 24) was a runtime mechanism for enforcing security policies including access control. It could restrict which code could read/write files, open sockets, or use reflection. In modern Java, JPMS provides module-level access control. The SecurityManager's access control was orthogonal to language-level access modifiers — it applied even to public APIs based on the calling code's trust level. With its removal, JPMS and explicit API design are the primary encapsulation tools.
Q80. How does encapsulation help with refactoring?
A: Encapsulation makes refactoring safe and local: (1) when a field is private, you can rename, retype, or split it without affecting any code outside the class; (2) when a method is private, you can extract, inline, or rewrite it freely; (3) you can change the data structure (e.g., switch from array to ArrayList) without client code knowing; (4) IDE tools like IntelliJ and Eclipse can confidently rename private members since the scope is limited. Wide-access members require searching all callers before refactoring.
Q81. What is the significance of the "module layer" in JPMS regarding encapsulation?
A: A module layer is a set of modules with their class loaders, used in plugin architectures to load multiple versions of the same module simultaneously. Each layer has its own module graph. From an encapsulation standpoint, modules in different layers are isolated: they cannot access each other's unexported packages even if they have the same module name. This enables strong plugin isolation, where plugins share a platform module layer but have isolated application module layers, preventing plugin code from accessing platform internals.
Q82. What is the java.lang.reflect.AccessibleObject.setAccessible() method and how does it break encapsulation?
A: setAccessible(true) on a Field, Method, or Constructor reflection object bypasses Java's access modifiers, allowing code to read/write private fields and call private methods. This is used by frameworks (Spring, Jackson, Hibernate) for dependency injection and serialization. It breaks encapsulation as a controlled compromise for framework usability. In JPMS, setAccessible(true) throws InaccessibleObjectException for unexported or un-opened packages, restoring encapsulation at the module boundary.
Q83. What is the difference between data hiding and data abstraction?
A: Data hiding is a mechanism (using private fields) that prevents direct access to the internal state. It is about access control. Data abstraction is a design concept: presenting only the logically necessary interface to the outside world, hiding the complexity of how data is stored or processed. Data abstraction can be achieved without data hiding (e.g., an abstract description of operations), but in Java, encapsulation/data hiding is the primary mechanism for implementing data abstraction. Both together form the foundation of good OOP design.
Q84. Can a record have mutable components?
A: A record's components are always declared as private final, so the references themselves are immutable (cannot be reassigned). However, if a component's type is a mutable class (e.g., Date, List), the object pointed to can still be mutated through that reference. To make a record truly immutable, use List.copyOf() in the compact constructor and return unmodifiable views from accessors, or use only immutable types as components. Java's built-in record provides syntactic convenience but not automatic deep immutability.
Q85. How does the Proxy pattern use encapsulation?
A: The Proxy pattern wraps an object and controls access to it. From an encapsulation perspective, the proxy hides the real object's reference (kept private) and can add cross-cutting concerns (logging, caching, security checks, lazy loading) without changing the subject's class. Dynamic proxies (java.lang.reflect.Proxy or CGLIB) use reflection behind the scenes but present a clean interface to clients. Spring AOP uses dynamic proxies to add transactional, security, and caching behavior transparently — the encapsulated business logic stays clean.
Q86. What is method visibility in inheritance chains?
A: When a subclass overrides a method: (1) it cannot reduce access (private overriding public is a compile error); (2) it can widen access (protected to public is fine); (3) a private method in a parent cannot be overridden at all — the subclass can define a method with the same name and signature, but it is a new independent method, not an override; (4) if you annotate a method with @Override and it turns out to be hiding rather than overriding (e.g., both are static), you get a compile error.
Q87. What is the "Flyweight" pattern and how does encapsulation enable it?
A: The Flyweight pattern shares common intrinsic state among many objects to reduce memory consumption. It relies heavily on encapsulation: the flyweight factory keeps a private cache (map) of existing flyweight objects; clients obtain flyweights only through the factory; the flyweight's internal state is private and immutable (intrinsic state). Since clients cannot directly create flyweights or mutate their state, the factory can safely return the same instance for equivalent state. The String pool in Java is the classic JDK example of the Flyweight pattern.
Q88. What are "wither" methods and how do they support immutability?
A: "Wither" methods (also called "with" methods) are a convention for immutable objects: instead of a setter that mutates state, a withFieldName(value) method returns a new instance with the changed field and all others unchanged. Example: person.withAge(31) returns a new Person with age 31 and the same name, email, etc. This is how records can be "modified" — person = new Person(person.name(), 31) or via a custom with method. Java's Stream API and date/time API (LocalDate) use this pattern extensively.
Q89. What is the difference between encapsulation and data validation?
A: Encapsulation is the structural mechanism (private fields + public methods). Data validation is the logic that enforces business rules (age must be positive, email must contain @). Encapsulation makes data validation practical: since all mutations go through setters or constructors, validation can be placed in those methods and enforced consistently. Without encapsulation (public fields), validation must be repeated everywhere the field is set. Bean Validation (JSR 380, @NotNull, @Min, @Max) adds declarative validation on top of encapsulated classes.
Q90. How does Lombok interact with encapsulation?
A: Project Lombok generates boilerplate encapsulation code at compile time via annotation processing. @Getter generates getter methods, @Setter generates setters, @Value creates an immutable class (all fields private final, no setters, class is final), @Builder generates a builder. Lombok respects encapsulation: fields remain private; only the appropriate accessors are generated. @Value in particular is a concise way to create immutable classes before records were introduced. Critics argue Lombok obscures what code is generated; proponents value the boilerplate reduction.
Q91. What is the visibility of constructors and how does it affect object creation?
A: Constructor visibility controls who can create instances: private — only within the class (Singleton, factory method, utility class); default — only within the package (for package-internal objects); protected — within package and by subclasses (for abstract-like classes meant to be subclassed); public — anyone can instantiate. Choosing the right constructor visibility is part of API design: factories often use private constructors with static factory methods (valueOf(), of(), getInstance()) to cache instances, control subclassing, or return subtypes.
Q92. What is the "Law of Demeter" and how does it relate to encapsulation?
A: The Law of Demeter (also called "principle of least knowledge") states that a method should only call methods on: (1) its own object (this); (2) objects passed as parameters; (3) objects it creates; (4) component objects (fields). It should not call methods on objects returned by other method calls (avoid "train wrecks" like a.getB().getC().doSomething()). This principle promotes encapsulation: if you navigate deep into an object graph, you depend on the internal structure of intermediate objects. Violations indicate that something that should be encapsulated internally is being exposed to the outside.
Q93. What is the difference between a POJO and a JavaBean?
A: A POJO (Plain Old Java Object) is any Java class that does not extend framework-specific classes or implement framework-specific interfaces — it has no special constraints. A JavaBean is a POJO that additionally follows the JavaBeans convention: private fields, public no-arg constructor, public getters/setters. All JavaBeans are POJOs, but not all POJOs are JavaBeans. Records are POJOs (no special superclass) but not technically JavaBeans (accessor names don't follow getXxx() convention, no no-arg constructor, no setters). Spring accepts both JavaBeans and records for various use cases.
Q94. How do enums use encapsulation?
A: Enum constructors are implicitly private, preventing external instantiation — enum constants are the only instances, and they are created by the JVM during class loading. Enum fields should be private final to make enum constants immutable (an enum constant with mutable fields can have its state changed, which is surprising). Enums can have private methods for internal shared logic. The enum body is a perfect example of encapsulation: rich behavior (methods) with controlled, fixed state (constants), and no external instantiation possible.
Q95. What are "data classes" in Java (before records) and what are their encapsulation trade-offs?
A: Before records (Java 16), developers created data classes manually: private fields, getters (and sometimes setters), equals, hashCode, toString. The trade-offs: (1) verbose boilerplate prone to bugs (forgetting a field in equals); (2) mutable by default (setters provided); (3) need for careful defensive copying of mutable fields; (4) no compile-time guarantee of immutability. Records solve the verbosity and immutability problems but at the cost of flexibility (no superclass, final, fixed component set). For complex domain objects, a manually crafted immutable class is still sometimes preferred.
Q96. What is the principle of "design by contract" and how does encapsulation enable it?
A: Design by contract (DbC), originating from Eiffel, specifies preconditions (what caller must guarantee), postconditions (what the method guarantees after execution), and invariants (properties always true of the object). Encapsulation enables DbC by ensuring that invariants can only be violated through the class's own methods, not by external field manipulation. In Java, preconditions are checked in method bodies, postconditions via assertions, and invariants via checks in every constructor and setter. Without encapsulation, invariants are unenforceable because any code can corrupt the fields directly.
Q97. What is an invariant and how does encapsulation protect it?
A: A class invariant is a property that must remain true for all valid instances of the class throughout their lifetime. Example: for a Circle class, the invariant might be "radius must be positive." Encapsulation protects invariants by: (1) the constructor validates the invariant before creating the object; (2) setters validate before allowing a change; (3) since fields are private, no external code can corrupt the state bypassing validation. If fields were public, any code could set circle.radius = -5, violating the invariant.
Q98. What is the "snapshot" pattern and how does it use immutability?
A: The snapshot pattern captures the state of a mutable object at a specific point in time, creating an immutable snapshot for later reference or undo functionality. The snapshot is an immutable value object (or record) holding a copy of all relevant fields. Encapsulation is key: the snapshot takes a deep copy of the mutable source's private state. This pattern is used in undo/redo systems, audit logs, event sourcing (capturing domain events as immutable facts), and version control systems.
Q99. What happens with access to members through reflection in a JPMS-enabled project?
A: In a JPMS project, reflection respects module boundaries: (1) if a package is exported but not opened, reflection can see public types and public members only; (2) if a package is opened (via opens in module-info.java), reflection can access all members including private ones via setAccessible(true); (3) if a package is neither exported nor opened, reflective access fails with InaccessibleObjectException; (4) you can use --add-opens JVM flags as a command-line workaround. This is the "strong encapsulation" of the module system applied at runtime.
Q100. What is the compile-time safety of records compared to manual immutable classes?
A: Records provide stronger compile-time guarantees: the compiler automatically ensures all components are assigned in the canonical constructor, that there are no setters for components, and that the class is final. With a manual immutable class, the developer must remember to: declare the class final, declare each field private final, write the constructor assigning every field, omit setters, and perform defensive copies. Forgetting any of these steps silently breaks immutability. Records remove this entire category of human error. However, records cannot add instance fields beyond their declared components, which limits their use to pure data carriers.
Q101. What is the difference between a local record and a regular record (Java 16+)?
A: Java 16 also allows records to be declared locally inside a method (local records). A local record is always implicitly static (it has no access to the enclosing instance). It is useful for creating a lightweight named tuple within a method without polluting the class's namespace. Local records obey the same rules as top-level records (immutable, final) but their scope is limited to the method. This is a concise way to encapsulate multi-valued return from helper logic inside a method without creating a separate file.
Q102. What is the risk of providing both a getter and a direct reference via a public field?
A: This would be a severe encapsulation violation. Having both a getter and a public field for the same state means there are two ways to access/modify it, which can lead to inconsistency if one path has validation and the other does not. It also makes it impossible to later change the implementation (e.g., switching from a field to a computed value) because both the getter and the field are in the public API. The rule is unambiguous: never expose fields publicly when you want encapsulation.
Q103. How does the Java Memory Model (JMM) interact with final fields and encapsulation?
A: The JMM provides a special guarantee for final fields: after a constructor completes, all writes to final fields are guaranteed to be visible to any thread that subsequently reads those fields — without any additional synchronization. This is called the "final field freeze" guarantee. It means that if you publish an object safely (no data race on the reference itself), all threads will see the correct values of its final fields. This is what makes immutable objects (with only final fields) inherently thread-safe. Non-final fields have no such guarantee without synchronization.
Q104. When should you prefer records over traditional immutable classes?
A: Prefer records when: (1) the class is purely a transparent data carrier (DTO, value object); (2) you want compiler-enforced immutability; (3) you want automatic equals, hashCode, toString; (4) you do not need to extend another class; (5) the component names are meaningful as the public API (no need for custom getter naming). Prefer traditional immutable classes when: (1) you need to extend a class; (2) you need fields beyond the components (e.g., a cached hash); (3) you need custom equals/hashCode logic; (4) you need getXxx() naming for JavaBeans compatibility; (5) the class is complex enough that the builder pattern is needed.
Q105. What are the encapsulation implications of using records in a REST API (JSON serialization)?
A: When using records as DTOs for REST APIs with Jackson, you need to configure Jackson to handle records properly (Jackson 2.12+ supports records natively). Records use accessor names without "get" prefix (x() not getX()), which Jackson 2.12+ recognizes. Earlier versions need @JsonProperty or a custom property naming strategy. From an encapsulation standpoint, records as DTOs are ideal: they are immutable, have a clean representation, and prevent accidental mutation of request/response objects as they pass through the application layers.
| Technique | Java Version | Use Case | Immutable? |
|---|---|---|---|
| Private fields + getters | All versions | General encapsulation | Optional |
| final class + final fields | All versions | Custom immutable class | Yes (with defensive copy) |
| Record | Java 16+ | Value/data carrier | Yes (structurally) |
| Sealed class | Java 17+ | Controlled type hierarchy | Optional |
| Module exports | Java 9+ | Module-level hiding | N/A |
| Builder pattern | All versions | Complex object construction | Yes (product is immutable) |
| Enum | Java 5+ | Fixed set of constants | Yes (if fields are final) |
Post a Comment
Add