所以我读过这个叫做SOLID (mixed with) Writing Testable Code的东西。然后特别是关于 D 部分。在使用语言库提供的原始类型或方法/类时，如何遵循这些准则。
是否还需要对数组使用依赖注入（java ( new int[64]) 或 FileWriter 的类成员？这些需要使用 DI 注入还是类仍然可以实例化它们？
您应该遵循上述指导方针走多远？
我不是在寻找特定语言的答案（如果可能的话）。恕我直言，答案应该适用于，例如 PHP、Python Java、哎呀，甚至 C
您通常不会注入原语或DTO / POJO类对象。原因是那些是：
FileWriter是不同的，因为它与上述观点完全相反。我不能简单地在测试中对它进行存根，并在没有一些强有力的假设的情况下使其工作——比如，我假设未来每个运行此代码的开发人员都会在他的机器上拥有特定的文件。这对于单元测试通常是不可行的，也是在这些情况下应用 DI 的原因之一。
这些问题来自FileWriter作为两个不相关组件之间的通信点的事实 - 您的应用程序和文件系统。在大多数情况下，任何进行这种集成（在您的应用程序和 DB/网络/文件/REST 等之间）的类都应该被抽象和注入。
注入数组是多余的。注入文件编写器是绝对必须的。事实上注入作家是不够的。文件编写者与外部世界进行大量交互，而您不希望这样。文件编写器应该被包装在它自己的类中，并且永远不要被直接调用。
相反，注入 FileWriterWrapper 的接口。因此，依赖性得到控制。此外，单元测试中的文件交互是一个主要的痛点。不惜一切代价避免它。数据库交互也是如此。事实上，与外部世界的所有交互都应该在单元测试中被存根/模拟。
美妙之处在于，SOLID 设计和可测试性齐头并进。好的设计意味着可测试的代码。如果您发现很难测试某些代码，通常表明您的设计存在缺陷。