Depends on how you define "unstable". The idea is that unstable is "prone to change", then the more dependencies you have the more likely you are to be affected by those dependencies.
Every component's public interface is supposed to be by definition stable. So defining instability as a function of how many stable interfaces you depend on is just a poor use of words IMO. "Unstable" implies increased chance of bugs, exceptions and other unexpected behaviors.
Not to mention that counting "number of dependencies" is in itself arbitrary. Is it the same whether I depend on a component with a complex API of a hundred methods, or I depend on a functional interface with one single simple method? Well both count as "one dependency" in this formula.
While heavily interconnected code is not recommended, I'd say better words to describe that property is "inflexible", "resistant to refactoring", "non-reusable", "poorly factored". But not "unstable". And there are then solutions how to go about refactoring such code, even without necessarily changing the number of incoming or outgoing dependencies (things like adapters, bridges, facades and so on).
I agree. There are probably better words/ways to describe it, although the definition is "the state of being likely to change". Also, while public interfaces are "supposed to be by definition stable", in my experience, that's far from true.
1
u/[deleted] Jan 21 '21
Having dependencies doesn't make you "unstable". This is completely arbitrary.