What is an Entity vs a Value Object?
Entity vs value object in OOP — identity vs structural equality, mutability and domain-driven design examples in Java.
Expected Interview Answer
An entity is an object distinguished by a persistent, unique identity that remains stable across its lifetime even as its attributes change, while a value object has no identity at all and is defined entirely, and interchangeably, by its current attribute values.
A Customer is an entity: even if their name, address, and email all change over the years, the system must still recognize them as the same customer via a stable identifier (a customer ID). A Money amount or an Address, by contrast, is typically a value object: a $50 amount is indistinguishable from any other $50 amount, so there is nothing to track beyond the value itself. This distinction, central to domain-driven design, drives two very different implementation choices: entities are usually mutable and compared by identity (equals compares IDs), while value objects are usually immutable and compared structurally (equals compares all fields). Getting this classification wrong — treating a value like Money as an entity with an ID, or treating a Customer as a plain value object — leads to subtle bugs around equality, caching, and change tracking.
- Correctly separates identity concerns (entities) from data concerns (values)
- Guides correct equals/hashCode implementation for each kind
- Prevents identity-tracking bugs and unwanted aliasing bugs
- Forms the foundation of sound domain-driven design modeling
AI Mentor Explanation
A specific player, say Virat Kohli, is an entity — he remains the same tracked individual across an entire career even as his batting average, team, and form all change over time; the system always knows it’s still him via a stable player ID. A recorded “century” (100 runs), however, is a value object — one century is indistinguishable from any other century, there’s no identity to a specific hundred beyond the number itself. Entities need a stable ID that survives change; value objects are just interchangeable data.
Step-by-Step Explanation
Step 1
Ask if identity must persist through change
If the object must remain “the same one” even as attributes change, it is an entity.
Step 2
Give entities a stable identifier
Use a dedicated ID field, and base equals()/hashCode() on that ID alone.
Step 3
Model everything else as a value object
If the object is fully described by its current data, treat it as an immutable value object.
Step 4
Compare value objects structurally
Base their equals()/hashCode() on all attributes, never on identity or reference.
What Interviewer Expects
- A precise definition contrasting identity-based vs value-based equality
- A correct example of each (Customer as entity, Money as value object)
- Awareness of the mutability difference (entities often mutable, values usually immutable)
- Recognition that misclassifying a concept causes equality/caching bugs
Common Mistakes
- Comparing entities by all fields instead of by identity
- Giving a value object an artificial ID field it doesn't need
- Assuming all classes with multiple fields are entities
- Forgetting that an entity's identity must remain stable even when every other field changes
Best Answer (HR Friendly)
“An entity is something tracked by a stable identity over time, like a customer, even as their details change — you compare entities by that ID. A value object, like an amount of money, has no identity of its own and is just defined by its data, so two with the same value are considered equal. Getting this distinction right early in modeling avoids a lot of subtle bugs later.”
Code Example
class Customer { // Entity: compared by identity
private final String customerId;
private String email; // mutable, identity stays stable
Customer(String customerId, String email) {
this.customerId = customerId;
this.email = email;
}
@Override
public boolean equals(Object o) {
if (!(o instanceof Customer c)) return false;
return customerId.equals(c.customerId); // ID only, not email
}
@Override
public int hashCode() { return customerId.hashCode(); }
}
final class Money { // Value object: compared structurally
private final long cents;
Money(long cents) { this.cents = cents; }
@Override
public boolean equals(Object o) {
return o instanceof Money m && cents == m.cents;
}
@Override
public int hashCode() { return Long.hashCode(cents); }
}Follow-up Questions
- How should equals() differ between an entity and a value object?
- Can an entity contain value objects as fields?
- Why is Money usually not modeled with its own unique ID?
- What bugs can occur if a value object is mistakenly compared by identity?
MCQ Practice
1. The defining trait of an entity is?
Entities are recognized by a persistent identifier, independent of how their other attributes change.
2. A value object's equals() method should typically compare?
Value objects have no identity, so equality is structural — based on all attributes.
3. Which is the more natural fit for an entity?
A Customer needs a stable identity tracked over time, unlike Money, Coordinate, or DateRange.
Flash Cards
Entity vs value object, in one line? — Entity = identity persists through change; value object = defined entirely by current data, no identity.
How are entities typically compared? — By a stable ID field.
How are value objects typically compared? — Structurally, by all attribute values.
Example of each? — Entity: Customer. Value object: Money.