memory-leaks

Still reachable: lots of words in many pages.
git clone https://git.kevinlegouguec.net/memory-leaks
Log | Files | Refs | README | LICENSE

commit 45fb3475a1900786de4d80d21f94cd6ad85a5cfa
parent 49539c7d0d625be61541118c14616ddcb0af9bb5
Author: Kévin Le Gouguec <kevin.legouguec@gmail.com>
Date:   Mon,  2 Jul 2018 18:15:56 +0200

Start adding notes on talks

Diffstat:
MREADME.md | 2+-
Atechnical/reviews/talks.md | 46++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md @@ -1,5 +1,5 @@ # Peniblec's Memory Leaks -## still reachable: 3726 words in 6 pages +## still reachable: 3957 words in 7 pages Hi! I am a software engineer interested in [a bunch of things]. diff --git a/technical/reviews/talks.md b/technical/reviews/talks.md @@ -0,0 +1,46 @@ +# Sandi Metz - Nothing is Something + +:::: tags +- OOP +- Ruby +:::: + +Some insightful thoughts on OOP. + +Clever examples of message-passing to get rid of conditionals. + +Prefer composition with dependency injection to inheritance: +inheriting to override a method really means that the parent class had +a default "null" behaviour that can be injected explicitly. + +Name the role, make an interface for it, and make classes that +implement each behaviour (the null one and the specialiazed one). +This will make it easier to compose specializations (i.e. save you +from multiple inheritance). + + +# Sandi Metz - Rules + +:::: tags +- OOP +- Ruby +:::: + +Some theory-crafting on rule-following, then the actual rules, which +amount to + +- small classes, +- tiny methods, +- few parameters. + +At the 16-minute mark, an interesting interaction between Metz and a +programmer starting to apply these rules: the programmer wonders when +they will be able to understand the new application "the same way" +they understood the old one. I.e. will they ever reach a point where +they have a complete mental map of every interaction between every +object, the same way the used to have a complete mental map of the old +monolithic, sequential application? + +Metz's response is that nope, this will never happen; they will "cease +to care" instead. In exchange, they will be able to make localized +changes without worrying about breaking the whole application.