Question

我们在C＃解决方案中出现了一种模式问题。

初步想法： 我们有一组功能（主要是计算），这些功能在几个项目中是必需的。我们想象我们的解决方案是模块化的 - 每个功能都是作为类库实现的，而不是在其他项目中作为.dll引用。

第一期： 发生的事情是，库有类，它们指定了进行数学运算所需的输入数据。由于单个库可以在许多项目中使用，我们最终为每个项目编写映射，将项目域对象移植到输入数据类。这很乏味，因为我们大多是进行一对一的转换 - 这些类基本相同。

思想： 我们认为我们将使用接口而不是类来指定输入数据来解决我们的问题。这样我们就可以简单地用接口标记我们的域类，我们就不用再进行映射了。

当前问题： 我们现在有一个完整的界面定义和在计算方法中使用这些接口的混乱。 E.g。

public interface ILevel2Child
{
}

public interface ILevel1Child<TLevel2Child> 
    where TLevel2Child : ILevel2Child
{
    List<TLevel2Child> Children { get; }
}

public interface IParent<TLevel1Child, TLevel2Child>
    where TLevel1Child: ILevel1Child<ILevel2Child>
    where TLevel2Child: ILevel2Child
{
    List<TLevel1Child> Children { get; }
}

当我们最终在方法或界面中使用IParent接口时，我们会继续拖动这些疯狂的长签名。

问题：

我们开始使用接口的想法是不是很糟糕？
如果没有，我们指定接口的方式有问题吗？
如果还没有，有什么方法可以阻止这种疯狂的签名模式吗？

补充说明： 我们从

public interface ILevel2Child
{
}

public interface ILevel1Child
{
    List<ILevel2Child> Children { get; }
}

public interface IParent
{
    List<ILevel1Child> Children { get; }
}

但这阻止了我们做

public class Level2Child : ILevel2Child
{
}

public class Level1Child : ILevel1Child
{
    List<Level2Child> Children { get; }
}

public class Parent : IParent
{
    List<Level1Child> Children { get; }
}

这是不可接受的。

通过接口

0 个答案: