complexity is a goldilocks thing. too simple and too complex are both bad. finding the balance is required. also, often times complexity can be tamed by subdividing the protocol or code into separate components that layer, this is the Unix maxim of "make it do one thing, and do it well" applied to architecture

Replies (2)

oh yeah, this is often called "composability" these days, and is the data model strategy used in Go with anonymous struct fields that overload a type with methods from multiple separate other types or interfaces. Composition > Inheritance it is related to the principles of Domain Driven Design also, which is about analysing your code to architect it as composable layers. solves SO MANY BUGS just by applying this analysis to a codebase. almost half the time, i think, the worst bugs come from breaching interfaces and not using encapsulation, creating hidden bindings between two types that often you miss because you didn't look to see. haha.