我有以下课程：
类验证器{
私有最终SchemaFetcher schemaFetcher;
@注入
验证程序（SchemaFetcher schemaFetcher）{...}
}
class DatabaseSchemaFetcher类实现SchemaFetcher {
@Override
架构loadSchema（final SchemaDefinition schemaDef）;
@Override
boolean compareSchemaWithSource（最终SchemaDefinition schemaDef，最终Schema UpdatedSchema）;
}
这只是示例之一，我还有其他类似的类，我将它们作为依赖项注入到其他类中。但这使我的SchemaFetcher类像一个单例，并且我一直将schemaDefinition传递给它的每个方法。这似乎非常程序化，我想将SchemaDefinition实际上作为DatabaseSchemaFetcher类的实例变量，但是在那种情况下，我将无法将SchemaFetcher对象注入到Validator类中，而应该这样做
validate（String schemaName）{
SchemaDefinition schemaDef = buildSchemaDefinitionFrom（schemaName）;
SchemaFetcher fetcher =新的DatabaseSchemaFetcher（schemaDef）;
}
但这使我与获取程序紧密耦合，这就是为什么我想首先使用依赖注入的原因。
我可以看到我可能有一个默认的构造函数，用于DatabaseSchemaFetcher，然后有一个setSchemaDefintion（）设置器来实现此目的，但是这违反了使用构造器完全构建对象的原则。
我该如何改进它使其不具有程序样式的访存器，而又将依赖项注入到构造函数中？我更喜欢构造函数注入，因为它清楚地定义了我的依赖关系，而无需任何人研究类的实现来弄清楚如果使用工厂或服务定位符，则该类使用的依赖关系。
最佳答案
依赖注入是那些很好的想法之一，它看起来是如此好，以至于严重滥用了它。我不会使用DI框架将Fetcher注入Validator中。相反，我会让DI框架将工厂注入“ main”中。工厂使用适当的SchemaDefinition创建Fetcher，并将其传递给Validator。
请记住，我们希望将“ main”与应用程序的其余部分分隔开，所有依赖项都应从“ main”指向应用程序。该应用程序不应该知道“ main”。即“ main”是应用程序的插件。
通常，应使用DI注入“ main”，然后main使用更多传统技术将工厂，策略或只是常规的旧抽象接口传递给应用程序。