Prototype pollution occurs when changing a base prototype changes the behavior of many objects that inherit from it. Property lookup traverses the prototype hierarchy, so a modification can ripple through derived objects at runtime. section 1.2
Student and Person
If Student objects inherit from Person, a change to Person can affect every Student, even when those objects were already created. The prototype hierarchy saves memory but makes downstream behavior harder to isolate. section 1.2
Common design responses expose different trade-offs:
- Copy properties into new objects or use mixins to reduce unintended downstream changes; accept a larger memory footprint because each object stores another copy. section 1.2
- Use constructors or classes behind factory functions and encapsulation boundaries rather than exporting mutable object literals directly. section 2.3
- Use class and extends syntax when a prototype chain is desired, while recognizing that classes remain syntactic sugar over constructor functions. section 2.3
Encapsulated transaction state
A Transaction class keeps fee data in a private field, while HashTransaction inherits public behavior. Private access such as tx.#feePercent throws a SyntaxError, limiting accidental external changes.
