C# 从接口到类的转换，糟糕的设计还是小违规？

我有一个问题，当我在接口上构建层次结构时，如何处理这些情况，然后我有一个基本的抽象实现类和许多子类——具体的实现者。 但是假设其中一个子类有两个额外的属性，这些属性没有包含在接口中。但当我使用接口时，我需要它们。从界面浇筑到直接混凝土类是一种不好的做法吗？或者我可以通过继承将这种情况（接口中不包括两个额外的属性）形式化为基本接口的新扩展， 当一个接口从另一个接口继承时，可以安全地将其转换为派生接口，而不是转换为类。什么选择是最正确的

下面是一个例子：

public interface IToken {
     string Tag {get;}
     string Content {get;}
     object CalculatedValue {get; set;}
     string ValueFormat {get;}
}

// inheritance of interface
  public interface ISimpleToken: IToken {
       string Key {get; set;}
  }

// OR!!!!!
  class SimpleToken: IToken {

    // ....interface members

    ....
    public string Key {get; set; }
  }

---

一般的经验法则是，如果要通过接口公开API，则应始终使用接口。你的接口应该只包括你想公开的东西。如果您只需要在该接口的实现内部使用它，那么它就会进入类中

另一部分，“视情况而定”。通常情况下，在某个时候，您需要所有这些实现的集合，因此您需要通过公共基接口/类引用它们

编辑：如果您发现需要从基类转换接口，那么您“可能”做错了什么。如果多个接口具有相同的方法，则它属于基本接口。您可以使用泛型实现这一点

如果您有一个场景，其中派生类需要执行与基类不同的操作，那么您应该使用虚拟方法和重写

---

在派生类中添加一些东西是可以的，只要它不会改变接口（它不应该改变接口），因为如果使用接口，通常不想公开实现类。

“这取决于”。有时，使用更通用的接口并在特定代码中细化到特定实现“更好”。在这种情况下，我通常会权衡携带不必要的签名和其他程序将保持有效的保护措施的“成本”，即使它无法静态执行。请向我们提供一个基本示例，说明您所说的内容，而不是描述它。正如@user2864740所说，它可能是一种代码气味，或者有时，这可能是正确的做法。在任何情况下，您都可以确保为强制转换失败编写代码（并使用

is

或

as

而不是

（SomeType）

样式的强制转换（即在失败时引发的）。您可能也会发现这很有用：。现在还有一个等价的“模式匹配”if语句语法：

if（myObj是mytypemytypeobj）{}

在这种情况下，我可能会有

ISimpleToken

，但它仍然无助于处理

列表

，并且希望调用

键，例如，由于仍然需要获得一个
ISimpleToken
（或
SimpleToken
；添加接口是优化类型的次要步骤）。格式化它的方式似乎是正确的。如果您只是想构建第一个接口的派生接口，该接口包含多个属性，那么创建另一个接口更为正确。如果您计划构建依赖于原始函数中的成员的函数，那么最好只使用一个类。对于这种类型的东西，“是-是”与“能做”的关系是一种很好的思考方式。这里有一个类似主题的链接。所以，正如我所理解的——小的违规和脆弱的设计在代码中是完全被接受的，而这些代码对客户来说是不公开的，如果我100%确信演员阵容会成功的话？@NickReshetinsky code不欠任何承诺：）