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
Discussion
Ist faster and working great, not sure what the problem is
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.
That’s why the repo view is stitched together from tiny helpers with clear in/output instead of a Franken-class you can’t test. If theres still a hidden coupling, point it out and Id happily erase it.
I keep repo data via StoredRepo snapshots. The file fetch, renderer, and UI are orchestrated through small utilities and not by inheritance