我只需要實現接口的一些方法

Question

在我的項目中有一個界面。 在界面中有很多方法。 我們公司的其他開發人員繼承了某些類的接口並實現了我需要實現的所有方法天氣。 那個時候我遇到了一些錯誤。 “不實現接口成員”。 我怎么解決這個問題？ 例如：-

public interface IComplianceRepository
    {
        IList<ComplianceModel> LoadComplianceModel(Guid userId);
        bool CreateCompliance(ComplianceModel complianceModel);
        IList<ComplianceType> LoadComplianceType();
        IList<ComplianceStatu> LoadComplianceStatus();
        IList<UserDetails> LoadUsersBySchoolId(int schoolId);
        Compliance GetComplianceByComplianceId(int complianceId);
        bool UpdateCompliance(ComplianceModel complianceModel);
        UserProfile GetUserProfileDetails(Guid userId);
        FinancialCompliance GetFinancialComplianceByComplianceId(int ComplianceId);
        void GetComplianceModelByComplianceId(ComplianceModel complianceModel, int complianceId);
    }

許多開發人員使用上述接口並實現all方法。 但我不想實現以下方法

    IList<ComplianceModel> LoadComplianceModel(Guid userId);
    bool CreateCompliance(ComplianceModel complianceModel);

我怎么解決這個問題？

Answer 1

你不能。 存在Interface的唯一原因是整個合同必須在實現它的類中實現。

Answer 2

如果您不能或不想更改接口，則應實現這些方法並拋出NotSupportedException 。 我建議為此使用顯式接口繼承，因此虛擬方法不會出現在類中。

void IList<ComplianceModel> IComplianceRepository.LoadComplianceModel(Guid userId)
{
    throw new NotSupportedException();
}

作為BCL中的示例，您可以查看ReadOnlyCollection.ICollection.Add方法 。 它是一個顯式的接口實現，它會拋出NotSupportedException 。 這也是糟糕設計的一個例子，證明在.net 4.0中缺少IReadOnlyList<T>接口。

---

真正的解決方案是重構代碼。 擁有完全實現的較小接口。 看一下Interface segregation原則 ：

接口隔離原則（ISP）規定不應強迫客戶端依賴它不使用的方法。 ISP將非常大的接口拆分為更小和更具體的接口，以便客戶端只需知道它們感興趣的方法。

Answer 3

創建兩個接口，父和子。 家長會有你想要的，孩子會有其他人。

public interface Parent {
    // parent methods here
}

public interface Child : Parent{
    // child methods here
}

Answer 4

如果類實現了接口，則必須實現該接口上的所有功能。 接口是功能合同，因此聲稱滿足該合同的任何內容都必須實際這樣做。 現在，您無需在合同中有意義地實施所有內容。 例如，對於您知道不會使用的方法執行此操作的標准方法是：

public void SomeMethodIKnowIWontUse()
{
    throw new NotSupportedException();
}

因此，如果實際使用該方法，那么它將拋出異常。 （當你認為它不會被使用時，這表明你錯了，你應該實現它。）

請記住，這很快就會導致“代碼異味”。 如果你有很多不需要實現的對象成員那么顯然設計是錯誤的......

這里的另一種可能性是界面設計不正確。 也許它試圖為太多人做太多事情？ 這可能違反了單一責任原則 。 例如，使用此界面：

public interface CatchAll
{
    void FunctionForOneResponsibility();
    void FunctionForCompletelyDifferentResponsibility();
}

使用非常人為的名稱，很明顯這個界面有太多的責任。 它應該是這樣的：

public interface OneResponsibilitySatisfier
{
    void FunctionForThisResponsibility();
}

public interface AnotherResponsibilitySatisfier
{
    void FunctionForThisOtherResponsibility();
}

沒有規則說你需要有很少的接口，或者接口需要有很多成員。 每個人都應該為其責任提供有意義的功能合同，僅此而已。 如果巧合的話，你有一個用於滿足這兩個職責的類，它可以實現兩個接口：

public class CrossCuttingObject : OneResponsibilitySatisfier, AnotherResponsibilitySatisfier
{
    public void FunctionForThisResponsibility() { }
    public void FunctionForThisOtherResponsibility() { }
}

Answer 5

接口作為接口的實現者和用戶之間的契約存在。 用戶/消費者要求實施所有方法。 首先，問問自己，沒有這些方法的實現是否仍然有用。 如果是這樣，請問自己是否需要繼承此界面。

如果在此反射之后，您仍然有正當理由在不實現所有方法的情況下實現此接口，則可以創建存根方法：

IList<ComplianceModel> LoadComplianceModel(Guid userId)
{
   throw NotSupportedException();
}

或者，更危險，但可能破壞性更小：

IList<ComplianceModel> LoadComplianceModel(Guid userId)
{
   return null;
}

Answer 6

這是接口隔離的理想方案。 請參考此設計原則（oodesign.com/interface-segregation-principle.html）您需要分離合同，不要將所有雞蛋放在一個籃子里。