方法参数的数据封装考虑因素(依赖注入)

本文关键字：依赖 注入 参数 数据封装 方法 | 更新日期: 2023-09-27 18:24:14

我有一个spec translator，如下所示。

    //all specifications implement this base class
    public abstract class SpecBase
        {
            public abstract void Translate(IContext context);     
        }
 //spec translator implementation
        public interface ISpecTranslator
        {
            void Translate(IContext context);
        }

我需要注入SpecTranslator构造函数的依赖项。我有两种方式来表达这种沮丧。

解决方案1

 public class SpecTranslator:ISpecTranslator
    {
        IList<SpecBase> specs; 
      public SpecTranslator(IList<SpecBase> specs)
        {       
                this.specs = specs;
        }
    }

请注意，使用IList<SpecBase>目前有效，但解决方案2似乎提供了更多保护。

解决方案2:

 public class SpecTranslator:ISpecTranslator
    {
        ISpec spec;
      public SpecTranslator(ISpec spec)
        {       
                this.spec = spec;
        }
  }
    public interface ISpec
    {
        IList<SpecBase> specs {get;}
    }

然而，ISpec的实现在使用构造函数依赖注入时也存在同样的问题。

对这两种解决方案或其他解决方案的利弊有什么想法吗？

方法参数的数据封装考虑因素(依赖注入)

似乎为了"翻译"（分析）规范列表，在所有情况下都需要对给定的ISpec实例的内容进行销毁。必须获得一份清单并仔细查看。无论您编织了多少抽象层，SpecTranslator最终都需要一个列表。

在你的情况下，我认为ISpec是一家工厂。如果列表不是延迟计算的，则其中没有值。

此外，简洁性是一个重要的设计原则。由于ISpec没有增加任何功能或体系结构自由度，因此它没有自己的分量。

相关文章：