Abstractions.pdf

These are the slides from my talk titled “Abstractions: Friend, Foe or Frenemy” at Friendly Ruby 2025 in Romania.

Transcript

1. ABSTRACTIONS Friend, Foe or Frenemy?
2. Introduction Name: Abiodun Olowode Short Form: AB Current Position: CTO & Co-Founder Metrifox Based in: Essex, UK Nationality: Nigeria
3. ABSTRACTIONS Friend, Foe or Frenemy?
4. Agenda 01 What an abstraction is not! 02 What are abstractions really? 03 What makes a good/bad abstraction? 04 When and how to introduce abstractions 05 Code Examples all the way
5. Developers love abstractions
7. Brew Your Own Coffee By Lucian Ghinda
9. Developers love abstractions
10. Many Developers love abstractions
11. What an Indescribable feeling!!
12. FRIEND STAGE
13. Examples of Abstraction Teams Platform Team Developer Experience Team Building Blocks Team Infra Team Core Team
14. Just trying to debug a missing email. Now, I’m 5 layers deep in NotificationContextRunnerProxyDecorator
15. How did I get here?
18. "All problems in computer science can be solved by another level of indirection." — David Wheeler (with a caveat by Tony Hoare: "...except for the problem of too many layers of indirection.")
19. Death by configuration
22. FOE STAGE
23. ….. Trapstraction
25. What an Abstraction… is not
26. Abstractions are not a way to hide messy code
27. Hiding a mess does not make it less messy Do we really need that Orchestrator Service?
28. Abstractions are not the path to making code elegant
30. Elegance isn’t about doing more It’s about clarity.. And clarity doesn’t always come from an extra layer
31. What is an abstraction, really?
32. A simplified representation of something complex that lets us think about the what and not the how
33. Abstractions hide details and expose intent
36. When do we need an abstraction?
37. DRY - Don’t Repeat Yourself
38. Abstractions should be about behaviour not structure
42. Let abstractions call out to you
43. When do we need an abstraction?
44. When we have shared behaviour
45. Duplication is far cheaper than the wrong abstraction — Sandi Metz
46. How to create an abstraction
47. Notification Abstraction
52. Identify Shared Behaviour Get the user’s preferred channel based on an identifier per event (eg. timeoff_approval) Send a message based on the channel preference per setting (email, sms, push) Craft different messages per channel (text message is diff. from email)
56. Tell, Don’t Ask
57. Behaviour should live where the knowledge is
58. The object with the data should own the behaviour, and be told, not interrogated
59. Within shared behaviour, identify uniqueness and where it would live
60. What is unique? Each identifier is different Each message is different
62. Scan Github Gist
67. Every good abstraction should aim to: ▪Preserve Clarity ▪Be easy to use ▪Expose intent while hiding details and complexity ▪Keep behaviour as close to data as possible
68. Closing Thoughts Duplication is fine (for now) Behaviour beats structure Tell, don’t ask The best use of a tool is to not use it unless you need to
69. POV: A dev using your abstraction 1 year later
71. ▪Connect with me @thedevaphorist Abiodun Olowode @abolowode