See: https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle 1) Framework: if your scheduler l

See: https://en.wikipedia.org/wiki/Liskov_substitution_principle https://en.wikipedia.org/wiki/Liskov_substitution_principle 1) Framework: if your scheduler logic is liskov substitutable with another scheduler, yes, you don't depend on the tasks 2) Shared Format: A writes to file, B reads it: again, the file is a transport mechanism that can be abstracted behind a Liskov substitutable interface. Serialization/Marshalling can abstract the format 3) Modifying a global variable? What a dumb question. 4) Crash puzzles: exception walls solve these as do standard error codes/exceptions in the liskov interface. 5) These are solved by liskov by interfacing with impls that have fallback. Or, read a book on a hundred and one patterns to solve it. 6) errors are part of interfaces. dumb example 7) cycled dependencies, again, don't matter if there are Liskov boundaries. Who cares what the impls are using if the Liskov boundaries are respected and defined. Exception: see next paragraph The only thing this is significant for is when two incompatible versions of the same library pollute the imports/classpath/whatever. THAT is a problem when dealing with lots of library imports and their downstream/transitive imports/dependencies, regardless of language in mature programming situations. But... there's a reason that's called "a dependency", so those are ... dependencies. Of course that really isn't listed.