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.

Reply to this note

Please Login to reply.

Discussion

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