When can Prototype be dangerous?

The Prototype pattern can be dangerous when cloning objects becomes unclear, uncontrolled, or incorrect, especially in systems with complex data structures and dependencies.

---

#1. Shallow vs. deep copying

The main danger is shallow copying, where only references are copied rather than nested objects. As a result, changes to the copy can affect the original, breaking data isolation:

To avoid this, you need to implement deep copying, which takes extra effort.

---

#2. Complex dependencies between objects

If an object references other objects (for example, a parent, a context, a resource pool), cloning can accidentally:

• copy unnecessary references and create circular dependencies;
• lose the connection to needed external state. This makes the behavior of copies hard to predict.

---

#3. Large hierarchies and object graphs

When deep-copying large structures, cloning becomes expensive in time and memory. It is especially dangerous with recursive references, you can accidentally create an infinite copying loop.

---

#4. Maintenance difficulty

If new fields are added to a class, a developer can forget to include them in clone(), leading to partially copied objects and hard-to-catch bugs.

---

#5. Violating an object's invariants

Some objects are not meant to be duplicated (for example, singletons, database connections, file descriptors). Copying them can lead to resource conflicts or inconsistent state.

---

#6. Implicit behavior

Cloning can hide important dependencies, the code does not show that a new copy is being created, which complicates debugging and understanding the data flow.

---

Conclusion: Prototype becomes dangerous when an object contains nested structures, external resources, or non-obvious dependencies. Without strict control over the type of copying and the data structure, it can lead to unpredictable behavior, memory leaks, and broken object isolation.