繼承一個空的接口可以嗎？

Question

我有這個通用方法：

        public void Send < TBiz, TEntity > (string serviceName, string pkName)
        where TEntity: class, IEntity
        where TBiz: class, BLL.Modules.INewSend 
        {
         var biz = DependencyFactory.Get < TBiz > ();
         var query = (biz.GetNotSent() as IEnumerable < TEntity > );
         NewSender < TBiz, TEntity > (serviceName, pkName, query);
        }

TEntity是我的數據模型對象（我的意思是數據庫表模型），可以是任何類型（如汽車、人類、鮮花等），但它們都具有ID屬性。 TEntity實現了IEntity接口。 IEntity是一個空接口，也可以是一個只有ID實現的接口，如下所示：

public interface IEntity
{
}

或者

public interface IEntity {
 public int ID {
  get;
  set;
 }
}

TBiz 是我實現INewSend業務類。 INewSend是一個簡單的接口，有 2 個實現：

public interface INewSend {
 void Send(long id, string userName);
 IEnumerable < IEntity > GetNotSent(); 
}

這段代碼工作正常，但我很好奇，就面向對象原則而言， TEntity類繼承空的IEntity接口是否可以？ 我這樣做是為了將不同的類（所有這些類都繼承IEntity接口）傳遞給Send方法。 IEntity接口也可以是具有ID屬性的接口，但我認為它不會改變問題，因為實現此接口的實體是完全不同的類型，盡管它們都具有ID屬性。

Answer 1

在面向對象的原則方面，TEntity 類繼承空的 IEntity 接口可以嗎？

沒有任何面向對象的原則會說擁有一個空的接口/空的類/空的其他任何東西都是不好的甚至是被禁止的。

從面向對象的角度來看，接口和類表示對象的（部分）身份。 因此，接口本身確實攜帶信息，無論它是否為空，即它定義了任何成員。

使用空接口作為所謂的標記接口是一種常見的做法，盡管還有其他方法來表示相同的意圖，例如屬性，它們每個都有優點和缺點。 與從 OO 的角度來看空接口的有效性（這是一個非常簡單的問題）不同，在特定場景中是否使用標記接口或屬性是基於意見的。

我這樣做是為了將不同的類（所有這些類都繼承 IEntity 接口）傳遞給 Send 方法。

為了獲得GetNotSent方法的強類型契約， GetNotSent您必須至少提供一些類似共同祖先的類型。 無論是接口（空與否）還是共同的祖先類都取決於您的特定設計。

IEntity 接口也可以是具有 ID 屬性的接口，但我認為它不會改變問題，因為實現此接口的實體是完全不同的類型，盡管它們都具有 ID 屬性。

接口的重點是為“完全不同的類型”提供一個視圖。 因此，我試圖指定什么是必須由每個類，以實施“是一個實體”和要素出來進入的公共屬性IEntity 。 這是完全有道理的。 然后， INewSend接口可以利用它並提供更一致的合約：

public interface INewSend 
{
    void Send(IEntity entity, string userName); // pass entity instead of its ID
    IEnumerable <IEntity> GetNotSent(); 
}

_注意：對於這個例子起見，我假設id最初被傳遞到Send是一個實體的ID。

Answer 2

沒關系，有時候我用一個空的界面只是為了對實體進行分類。