What that actually means?
I would like to get concrete examples.
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Looking for some feedback on my team's new open-source secrets vault project.
Felipe Araujo -
Our Rights, Our Future, Right Now - Celebrating Human Rights Day
Tatyana Bayramova -
Simple accordion without JavaScript
Rails Designer -
Metallics by Draneria | Free brushes, for Krita!
Draneria -
Top comments (5)
My OOP education is only semi-formal, so I could be totally offbase, but I'll say what I intuit this could mean:
Your code might change often, but your dependencies should be pretty stable in this regard.
dev.to changes many times per day. Our main dependency Ruby on Rails changes a couple times a year. dev.to has no code dependents at the moment and if they did, they'd have to deal with a lot of bullshit from our changes.
Internal changes that don't modify the API should be fine vs changes that affect the interface you're coding against.
In OOP land, that same principle would make sense. The qualities of
Humanprobably change less than the qualities ofProgrammer. And therefore, inheriting fromHumanseems more sensible.I may be totally interpreting this in a way that is totally offbase, someone correct me if I'm way off here.
@ben why do you say that dev.to has no code dependencies?
Do you mean that dev.to knows only the API of rails, and thus when rails changes internally but keep the API it doesn't affect dev.to?
So the phrase could be
trust the API not the implementationMake sense for me,, but I thought this was related to inheritance maybe I'm wrong.
Whoops sorry I meant to say dependents. Nobody is relating on our code via an API at this moment. Wrong word, I just fixed it.
You’ve got it Ben.
Sandi Metz (and I’m sure others) speak on this concept. Seek out YouTube vids or her books for more explanation on the topic.
@elizabet Jenerson do you know which talk from Sandi?