函数A对其他函数有3个依赖项。函数B对其他函数有3个依赖关系。函数C结合了这两个函数，并将提供函数A和B的依赖关系。
但是，如果函数C被用在另一个函数中，它结合了像C这样的函数，该怎么办？这是依赖关系的提供部分开始分解的时候。
我似乎找不到一个简单的答案；走的路"；在这种情况下。
"；阅读器monad"；看起来很有希望。尽管有人说依赖注入(框架(在OOP中是不好的，但它很好地解决了这个问题。
我希望你能帮我找到一个最佳实践。
由于这个问题被标记为依赖项注入，我假设的依赖项是指依赖项注入(DI(中使用的依赖项类型：数据库访问、web服务调用、时间提供程序、GUI视图-通常是策略。
有一个子集的策略，所有的策略都是确定性的，没有副作用-换句话说，纯粹的功能。当你把一个纯函数传递给另一个纯功能时，根据定义，你就是在定义一个高阶函数。没关系。
然而，一般来说，DI会使一切变得不纯洁。将一个不纯净的动作传递给一个函数会使组合的函数也不纯净。如果你想采用函数式编程，你必须以不同的方式建模。
阅读器monad并不能解决这个问题。
一个好的起点是功能核心，强制外壳架构，也就是Impuremi三明治。将不纯的动作推到系统的边界，并从其他纯函数中组成纯函数。