The Age of Our Mutant Overlords is Over

On immutability, Ruby, OOP, and Clojure. Find the associated article at https://deveo.com/blog/2013/03/22/immutability-in-ruby-part-1/

Rich Hickey talk "Persistent Data Structures And Managed References": http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey
Rich Hickey talk "Value of Values": http://www.infoq.com/presentations/Value-Values

Clojure Rationale: http://clojure.org/rationale
Clojure State Model: http://clojure.org/state
Guido quote from: http://www.artima.com/weblogs/viewpost.jsp?thread=7589
Matz quote from: http://markmail.org/message/cgrfvsncmko5ae7c#query:+page:1+mid:w273xdhvwqu5htgl+state:results
Rich Hickey immutability vs convention quote from: http://codequarterly.com/2011/rich-hickey/
Hamster (immutable data structures for Ruby): https://github.com/harukizaemon/hamster
Virtus gem for value objects: https://github.com/solnic/virtus
Values gem for value objects: https://github.com/tcrayford/values
ActiveRecord composed_of removal, Jose Valim's take: http://blog.plataformatec.com.br/2012/06/about-the-composed_of-removal/
Matt Wynne's hexagonal architecture talk: http://vimeo.com/44807822

Transcript

1. Immutability A.K.A. The Age of Our Mutant Overlords Is Over!
2. Definition An immutable object is one whose state cannot be changed after construction.
3. Definition An immutable object is one whose state cannot be changed after construction.
5. Rich Hickey Mutable stateful objects are the new spaghetti code: - Hard to understand, test, reason about - Concurrency disaster http://clojure.org/rationale
7. Joshua Bloch Immutable objects are simple. Classes should be immutable unless there’s a very good reason to make them mutable. If a class cannot be made immutable, limit its mutability as much as possible. Effective Java (2001, 2008)
8. Immutable Ruby? In the standard library In domain models
9. Immutable Ruby? In the standard library In domain models
11. 42 42 +! 2 42.oddify!
12. 42 42 +! 2 42.oddify!
13. "abc"
14. "abc" a = "abc"
15. "abc" a = "abc" a[1] = "d"
16. "abc" a = "abc" a[1] = "d" a
17. "abc" a = "abc" "adc" a[1] = "d" a
18. a = "abc"
19. a = "abc" h = {a => “value”}
20. a = "abc" a[1] = "d" h = {a => “value”}
21. a = "abc" a[1] = "d" h = {a => “value”} h[a]
22. a = "abc" nil a[1] = "d" h = {a => “value”} h[a]
23. a = "abc" nil a[1] = "d" h = {a => “value”} h[a]
24. Guido van Rossum Much of Ruby, especially its runtime, is much closer to Python’s [than Perl’s], with the exception of Ruby’s mutable strings, which I find an abomination. http://bit.ly/15FHC1b
25. Matz I rarely have such problems caused by mutable strings. Besides, Ruby is not a language to keep people away from horror. You can write ugly, scary, or dangerous programs in Ruby, if you want. It’s cost for freedom. http://bit.ly/10q6hUC
26. Rich Hickey There’s no such thing as a convention of immutability, as anyone who has tried to enforce one can attest. If a data structure offers only an immutable API, that is what’s most important. If it offers a mixed API, it’s simply not immutable. http://codequarterly.com/2011/rich-hickey/
27. a = [1, 2, 3, 4] h = {:a => 1, :b => 2}
28. a = [1, 2, 3, 4] h = {:a => 1, :b => 2} a << 5 h[:c] = 3
29. a.map { |n| n ** n }. select { |n| n.odd? }. take(2)
30. a.lazy. map { |n| n ** n }. select { |n| n.odd? }. take(2) Ruby 2.0 Enumerable::Lazy
31. harukizaemon/hamster a = Hamster.list(1, 2, 3, 4) h = Hamster.hash(:a => 1, :b => 2)
32. harukizaemon/hamster a = Hamster.list(1, 2, 3, 4) h = Hamster.hash(:a => 1, :b => 2) a.cons(5) h.put(:c, 3)
33. Immutable Ruby? In the standard library In domain models
34. Steve Freeman & Nat Pryce When designing a system, it’s important to distinguish between values [...] and objects [...]. Values are immutable instances that model fixed quantities. They have no individual identity, so two value instances are effectively the same if they have the same state. Objects, on the other hand, use mutable state to model their behavior over time. In practice, this means that we split our system into two “worlds”: values, which are treated functionally, and objects, which implement the stateful behavior of the system. Growing Object-Oriented Software, Guided by Tests (2009)
35. Eric Evans An object defined primarily by its identity is called an ENTITY. An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT. Immutability is a great simplifier in an implementation, making sharing and reference passing safe. It is also consistent with the meaning of a value. If the value of an attribute changes, you use a different VALUE OBJECT, rather than modifying the existing one. Domain Driven Design (2003)
36. Rich Hickey People accustomed to OO conceive of their programs as mutating the values of objects. They understand the true notion of a value, say, 42, as something that would never change, but usually don’t extend that notion of value to their object’s state. That is a failure of their programming language. These languages use the same constructs for modeling values as they do for identities, and default to mutability, causing all but the most disciplined programmers to create many more identities than they should, creating identities out of things that should be values. http://clojure.org/state
37. Identities Values Objects Entities Value objects
38. class User attr_accessor :id, :name, :address end
39. class Address attr_accessor :street, :zip, :city end
40. class Address attr_reader :street, :zip, :city def initialize(street, zip, city) @street = street @zip = zip @city = city end end
41. class Address attr_reader :street, :zip, :city def initialize(street, zip, city) @street = street @zip = zip @city = city freeze end end
42. class Address attr_reader :street, :zip, :city def initialize(street, zip, city) @street = street @zip = zip @city = city IceNine.deep_freeze(self) end end
43. class Address include Virtus::ValueObject attribute :street, String attribute :zip, String attribute :city, String end solnic/virtus
44. Address = Value.new(:street, :zip, :city) tcrayford/values
46. class User < ActiveRecord::Base def address @address ||= Address.new(street, zip, city) end def address=(address) self[:street] = address.street self[:zip] = address.zip self[:city] = address.city end end http://blog.plataformatec.com.br/2012/06/about-the-composed_of-removal/
47. Hexagonal Architecture http://vimeo.com/44807822
48. Summary - Immutable objects are ones whose state cannot be changed after construction. - Heavily used in functional programming, but have always been in OOP too. - Immutability makes programs easier to reason and test. Also makes concurrency much easier. - Some of Ruby’s standard data types are immutable, others are not. - Think twice before using mutation methods. - Collections can be used in an immutable way. Fully immutable libraries exist. - In domain models, there should be a distinction between objects and (immutable) values. - In most OO languages, there is only one language construct: The class - It is our responsibility as programmers to enforce the distinction.
49. Resources - Try Clojure! - Watch some Rich Hickey talks: - Persistent Data Structures and Managed References (http://bit.ly/yokcZ) - The Value of Values (http://bit.ly/PapkyI) - Read Growing Object-Oriented Software, Guided by Tests - Read Domain Driven Design
50. @teropa