Good software is 'orthogonal', that is, if you make a change to a component you shouldn't have to change other components. We all learn the basic concept of loose coupling when doing Comp Sci at Uni, but Andy Hunt and Dave Thomas in The Pragmatic Programmer (1999) were the first (that I had read) to express the concept in terms of orthogonality.
Orthogonal is just a fancy way to describe two planes being at right angles. For example, If you imagine a graph with x and y axes, for x and y to remain orthogonal any increase to x must leave y unaffected.
It's a nice way to consider component coupling, if you change one, it shouldn't impact others.
So what can this look like in the real world? This afternoon I came across a method that has a line looking a little like this:
$val = $state->getGeoModel()->getMetadata()->getBoundingBox();
Now, never mind the mind boggling number of assumptions this line makes (e.g. that each call *will* return an initialised object), it means that one method in one component needs to know how three different components work.
This code knows that a state object has a getGeoModel() method that in turn returns an object with a getMetadata() method. If we change the getGeoModel() method, we have to update this code. If we change the behaviour and values of the geomodel object itself, we have to update this code. If we change the metadata object, again, we have to update this code.
This increases the entropy risk by a factor of three.
A smarter approach, and one suggested in The Pragmatic Programmer, is to simply expose a getBoundingBox() method in $state. This way, we move the problem to the state object and reduce coupling in our implementation.
This will add complexity to the $state class, however we can apply the same principal up the chain as applied here.