markdown guide
 

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 Human probably change less than the qualities of Programmer. And therefore, inheriting from Human seems 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 implementation

Make 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?

Classic DEV Post from Jun 17

Should a button communicate the current state, the intended behavior, or both?

M Bellucci profile image
Computer Engineer and Ruby Developer since 2014.

Sore eyes?

dev.to now has dark mode.

Go to the "misc" section of your settings and select night theme ❤️