This is a horrible idea that will eventually make the situation of cyclical dependencies even worse.
Hitting cyclical dependencies is an indication that the code base is not being built in a composable fashion with layers depending on other layers. This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.
This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.
Also, dependency injection. It's possible to get rid of all dependencies if your code just refers to abstract interfaces and delegates the responsibility to provide concrete implementations to downstream dependencies.
Thanks for the reply. Do you feel this way too if external repos need this data as well? I advocated for the use of interfaces for these external packages to keep them self contained an not reliant on an external structs package for a few simple fields.
Absolutely, having very focused packages helps from an external consumer perspective as well.
Interfaces can help if you have multiple things that all implement the same functionality or you need to mock out for testing, but often times people will create interface bloat for things that are only implemented by a single struct and there’s no benefit to testing.
Comments
This is a horrible idea that will eventually make the situation of cyclical dependencies even worse.
Hitting cyclical dependencies is an indication that the code base is not being built in a composable fashion with layers depending on other layers. This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.
Also, dependency injection. It's possible to get rid of all dependencies if your code just refers to abstract interfaces and delegates the responsibility to provide concrete implementations to downstream dependencies.
Thanks for the reply. Do you feel this way too if external repos need this data as well? I advocated for the use of interfaces for these external packages to keep them self contained an not reliant on an external structs package for a few simple fields.
Absolutely, having very focused packages helps from an external consumer perspective as well.
Interfaces can help if you have multiple things that all implement the same functionality or you need to mock out for testing, but often times people will create interface bloat for things that are only implemented by a single struct and there’s no benefit to testing.