Immutable Object
(Redirected from immutable object)
Jump to navigation
Jump to search
An Immutable Object is a software object that cannot be changed.
- Example(s):
- Counter-Example(s):
- See: Data Object, Object-Oriented Design, Program Constant, Functional Programming, Log-Structured File System, Copy-on-Write, Log-Structured Merge-Tree, Append-Only, Hash Table.
References
2015
- (Helland, 2015) ⇒ Pat Helland. (2015). “Immutability Changes Everything.” In: Proceedings of the Conference on Innovative Data Systems Research (CIDR-2015).
2013
- http://en.wikipedia.org/wiki/Immutable_object
- In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in contrast to a mutable object, which can be modified after it is created. In some cases, an object is considered immutable even if some internally-used attributes change but the object's state appears to be unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object.
Immutable objects are often useful because they are inherently thread-safe. Other benefits are that they are simpler to understand and reason about and offer higher security than mutable objects.
- In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in contrast to a mutable object, which can be modified after it is created. In some cases, an object is considered immutable even if some internally-used attributes change but the object's state appears to be unchanging from an external point of view. For example, an object that uses memoization to cache the results of expensive computations could still be considered an immutable object.
- ↑ Goetz et al. Java Concurrency in Practice. Addison Wesley Professional, 2006, Section 3.4. Immutability
2005
- (Rodrigues & Liskov, 2005) ⇒ Rodrigo Rodrigues, and Barbara Liskov. (2005). “High Availability in DHTs: Erasure Coding Vs. Replication.” In: Proc. of the 4th International Workshop on Peer-to-Peer Systems. doi:10.1007/11558989_21
- QUOTE: High availability in peer-to-peer DHTs requires data redundancy. This paper compares two popular redundancy schemes: replication and erasure coding. Unlike previous comparisons, we take the characteristics of the nodes that comprise the overlay into account, and conclude that in some cases the benefits from coding are limited, and may not be worth its disadvantages.