Earlier quoted context omitted.
I suppose. Abstractly: A constraint is an invariant that must be true before and after the change. It doesn't matter if they are 'hidden' or 'visible'; if you must maintain the existing behavior , then you have to prove that no constraints are violated by the change you make. The effort you have to expend is proportional to the number of places where you have invariant that must be maintained. However. If you isolate…
> Since the volume is always >= the surface You'll find out that analogies to Euclidean geometry do not hold for software structure in general. That's a nice heuristic though. Just be wary that if you follow it blindly, you will inevitable optimize things into a counterexample where everything breaks down while your proof still finds it's the optimal. Static analysis is good, in moderation; dynamic validation is good…
...but, strictly, if you have a module with K public functions and P private functions the maximum possible number of unique external dependencies you have to track on the module is K.
If P > 0, then the 'api surface' of the module is smaller than the total set of functions.
If K = 0, the module has no external dependencies and you can do whatever you want.
I'm going to say with complete confidence that creating 'boxes' in your software where you minimize K creates maintainable software.
When K = P, you have a dumpster fire.