2. earliest evidence of double-entry bookkeeping
is the Farolfi ledger of 1299-1300.
3. The earliest evidence of
full double-entry bookkeeping
is the Farolfi ledger of 1299-1300.
Why am I talking about this?
4. The earliest evidence of
full double-entry bookkeeping
is the Farolfi ledger of 1299-1300.
Why am I talking about this?
...because we are amazingly lucky
that our idea creators are still alive!
5. Barbara Liskov
ACM Turing Award lecture (2009) 11:50
http://www.infoq.com/presentations/liskov-power-of-abstraction
6. The entire system should be broken up into
“Partitions”
Each has access to some hidden state
Each provides operations
Only interact by calling each others operations
7. Why doesn't she get to the point?
She's talking about 'Objects'!
8. Why doesn't she get to the point?
She's talking about 'Objects'!
Object Oriented Programming didn't exist...
9. Who invented OOP?
Alan Kay is credited with coining the term
Led research to develop SmallTalk
=> 1972 (40ish years ago)
10. Who invented OOP?
It developed later as the dominant methodology
when programming languages supporting
the techniques became widely available
(C++, Java, Delphi)
=> early-mid 1990s (20ish years ago)
"Actually I made up the term "object-oriented",
and I can tell you I did not have C++ in mind."
-- Alan Kay
11. I thought of objects
being like biological cells
and/or individual computers on a network,
only able to communicate with messages
(so messaging came at the very beginning)
– Alan Kay
12. Design is *all* about Dependencies
If you refer to something
---> you depend on it
When the things you depend on change
---> you must change
-- Sandi Metz, "Solid Design" GoRuCo 2009
13.
14.
15. A----
B-----
C -----> X
D-----/
E ---/
● if x changes everybody has to change!
● x better not change! It should be stable
16. /--> A
/---> B
Z ------> C
---> D
--> E
● if z changes no body cares!
● if c changes, only z may have to
● z is isolated!
17. J → K → L
● if L changes, K may have to
● Maybe J will too?
24. Single Responsibility
An object should have only a
single responsibility
One and ONLY ONE reason to change
If you have to use the word “AND” or “OR”
to describe your class....
25. Jim Weirich talk on SOLID
Jim asked: AR mixes domain + persistence
-- is it ok?
26. Jim Weirich talk on SOLID
Jim asked: AR mixes domain + persistence
-- is it ok?
Response:
● NO! As design gets complex and interactions
between objects get complex, it confuses
things.
● NO! It's harder to test.
27. Jim Weirich talk on SOLID
Jim asked: AR mixes domain + persistence
-- is it ok?
Response:
● NO! As design gets complex and interactions
between objects get complex, it confuses things.
● NO! It's harder to test.
Jim said: Maybe it IS OK in your case...!
● IT'S PRINCIPLES NOT RULES! up to you!
28. The DHH Factor
...later on twitter
@paulc: ... What are your thoughts on
separating logic + persistence?
29. The DHH Factor
...later on twitter
@paulc: ... What are your thoughts on
separating logic + persistence?
@dhh: Fuck. That. Shit. Same complete wank.
"Rails is not your application".
If you're building a web app, of course it is.
30. #find and the infinite protocol
If ActiveRecord models
Are your Domain Models
You are exposing an infinite protocol!
.where(:category => “Blah”).order(:name)
31. Interface Segregation Principle
Code should depend on
as NARROW protocol as possible
The protocol is the messages between objects
Not WIDE interfaces!
It's just encapsulation, right?
32. #find and the infinite protocol
If ActiveRecord models
Are your Domain Models
You are exposing an infinite protocol!
.find(:first)
33. Single Responsibility
Build models without referencing ActiveRecord?
Why?
● Faster tests
● Separate concerns for complex situations
● Expose a clean, domain-oriented interface
● Logic unrelated to persistence:
At the intersection of persistable objects
You often find business rules.
IT'S A THIRD PLAIN RUBY OBJECT!
34. Single Responsibility
Build models without referencing ActiveRecord?
How?
● FigLeaf approach?
– The gem “hides” all AR methods
(so you can't access them outside your model)
– You expose the functionality you mean
– It's domain driven
35. Single Responsibility
Build models without referencing ActiveRecord?
How?
● Domain Object approach?
– You keep AR models as thin as possible
– Add a separate object for Domain logic
that accesses the AR model
– Everybody else accesses the Domain object
36. ...thoughts
“There is no problem in computer science
that cannot be solved
by adding another layer of indirection,
except having too many layers of indirection”
37.
38. ...thoughts
@dhh
I hate the disconnect between design
patterns/abstract ideas and implementation
Your basic question should be “Is the code
better?”
