# Does "clean software architecture" exhibit crystaline structure? [closed]

I was thinking today about an analogy between entropy/crystal structure (in the domain of physics) and object-oriented polymorphism.

Uncle Bob Martin always talks about how high-level components must not depend on low-level components. He prescribes that instead both high and low-level components should depend on common abstractions.

I've been thinking about what the effect is of introducing such a "common abstraction". Particularly, what is the effect on the directed acylic graph representing depencies (either compositional or inheritance-based) between different classes in the software package? Is there some sense in which introducing the shared abstraction has reduced the entropy of the package (as observed by comparing the DAGs representing the package before vs after the introduction of the abstraction)?

My noob physics understanding is that crystaline structures have low entropy (or zero entropy), and are thus is some sense maximally ordered. My inspiration for writing this question was that introducing an abstraction into an OO project seems to (A) make the project more ordered (reducing the entropy of the system?), enabling dependency inversion and decoupling, and (B) have some "flattening" effect on the DAG of dependencies among classes in the package. Somehow the idea of a DAG exhibiting flat, regular structure (rather than complex, chaotic structure) made me think of crystals.

Let me be explicit about what I mean by a "flattening effect". Suppose we have classes A and B and C such that A depends on B somehow (e.g. via a composition relationship), and B depends on C.

  A -> B -> C


Introducing an abstraction (or two) enables a directed graph like the above to be turned into one that look like this:

  A -> X <- B -> Y <- C.


Here X and Y are abstract interfaces that are now depended upon by A/B and B/C, respectively. This second DAG has two nodes more than the first one, and the maximal path length within the DAG has decreased from two (in the first case DAG) to one (in the second). I think that this reduction in path length is what I mean when I say that the graph has become "flatter".

### Here are my questions:

• Is there some statistic that can be calculated from a project's class DAG to calculate its "entropy"? What is the definition of "software project entropy" that I'm looking for?
• Can my rough analogy between physical entropy and the order of a software package be made more precise?