0

这个问题看起来很奇怪，但我们确实有需要修复构造函数签名的情况。

例如，我希望它用于在 DI 中解析依赖项。如果构造函数被扩展并且需要更多参数，其中一些非常依赖于上下文，我就有麻烦了。
如果 DI 容器无法解决依赖关系，肯定会抛出异常，但这不是我认为的最佳方式。

我只是重构我们的应用程序并了解最初计划成为 DI 的良好候选者的东西现在由于故意的构造函数扩展而被破坏，而没有了解后果。阻止它的唯一方法就是开发人员之间的约定。
语言支持会很有帮助，但 C# 和 Java 都没有。

所以我认为这个功能没有实现应该有一些原因......为什么？

这是我们工厂的样子：

public class EntityBase : IEntity
{
   public EntityBase(IBusinessModel model, IAppContext context)
   {
   }
}

public class DescendatnEntity : EntityBase, IDescendatnEntity
{
   public DescendatnEntity(IBusinessModel model, IAppContext context, ...additional params...)
   {
   }
}

public interface IEntitiesFactory
{
     IEntity GetBaseEntity();
     IDescendantEntity GetDescendantEntity(...those additional params...); 
}

IBusinessModel和IAppContext单例，而附加参数是瞬态的。

如果只有调用者知道瞬态参数的值，工厂就不需要知道这些参数。

4

1 回答 1

0

You could use constructor chaining to provide your default implementation.

public class DescendantEntity : EntityBase, IDescendatnEntity
{

   public DescendantEntity(IBusinessModel model, IAppContext context, ...additional params...)
   {
   }
   public DescendantEntity(IBusinessModel model, IAppContext context)
       this(model, context, ...additional params defaults...)
   {
   }
}
于 2013-02-19T20:17:17.137 回答