Depend on things that change less often than you

#discuss #oop #design

What that actually means?
I would like to get concrete examples.

Top comments (5)

Ben Halpern • Jan 23 '19 • Edited

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.

M Bellucci • Jan 30 '19

@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.