The Prototype pattern's biggest pitfall is getting clone semantics wrong, specifically the choice between shallow and deep copying. A prototype is only useful if cloning produces an object that behaves independently from the original, so mishandling this defeats the pattern's purpose.
Key Points: • Java's default Object.clone() performs a shallow copy, so fields referencing mutable objects are shared between the original and the clone. • Shared mutable references mean changes to the clone can unexpectedly affect the original, and vice versa. • Deep cloning avoids that problem but must be implemented manually for every mutable field, which is easy to forget when the class evolves. • As fields are added to the class, clone() has to be kept in sync, or new fields silently end up shallow-copied. • Cloning objects that hold non-cloneable resources (file handles, sockets, database connections) is often meaningless or unsafe and should be avoided.
Example: Cloning a Person object that has a List<Address> field with a shallow copy leaves both the original and the clone pointing at the same list, so adding an address to the clone also changes the original's address list.
Interview Tip: A concise interview answer is:
"The classic pitfall is shallow vs. deep cloning: Java's default clone() is shallow, so any mutable reference fields end up shared between the original and the copy, causing subtle bugs. You have to deliberately deep-copy those fields and keep the clone logic in sync every time the class gains new mutable state."