简体   繁体   中英

I need Implement interface some methods only

In my project have an interface. In the interface have lot of methods. Our company other developers are inherited the interface in to some classes and implement the all method weather I need implement some methods only. That time I got some error. “Does not implement interface member”. How can I solve this problem? For example:-

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);
    }

Many more developers used the above interface and implement the all method. But I don't want implement the following methods

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

How can I solve this problem?

You can't. The only reason of an Interface to exist is so that the whole contract must be implemented in the classes that implement it.

If you cannot or don't want to change the interface, you should implement those methods and throw a NotSupportedException . I recommend using explicit interface inheritance for this, so the dummy methods don't appear on the class.

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

As an example in the BCL you can look at ReadOnlyCollection.ICollection.Add Method . It's an explicit interface implementation and it throws NotSupportedException . It's also an example for bad design, demonstrating the lack of an IReadOnlyList<T> interface in .net 4.0.


The real solution is refactoring your code. Have smaller interfaces which you implement completely. Take a look at the Interface segregation principle :

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Create two interface, parent and child. Parent will have exactly what you want, and child will have others.

public interface Parent {
    // parent methods here
}

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

If a class implements an interface, it has to implement all of the functionality on that interface. An interface is a contract of functionality, so anything which claims to satisfy that contract must actually do so. Now, you don't have to meaningfully implement everything in that contract. The standard way to do this for a method you know you're not going to use, for example, would be this:

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

So if that method is ever actually used then it will throw an exception. (This would be an indication that you were wrong when you thought it wouldn't be used, and you should implement it.)

Keep in mind that this can quickly lead to a "code smell." If you have a lot of object members which don't need to be implemented then clearly the design is wrong...

Another possibility here is that the interface is incorrectly designed. Perhaps it's trying to be too many things to too many people? This could be a violation of the Single Responsibility Principle . For example, take this interface:

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

Using terribly contrived names, it's clear that this interface has too many responsibilities. It should be this instead:

public interface OneResponsibilitySatisfier
{
    void FunctionForThisResponsibility();
}

public interface AnotherResponsibilitySatisfier
{
    void FunctionForThisOtherResponsibility();
}

There's no rule that says you need to have few interfaces, or that an interface needs to have many members. Each one should provide a contract of meaningful functionality for its responsibility and nothing more. If by coincidence you have one class which would be used to satisfy both responsibilities, it can implement both interfaces:

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

Interfaces exist as a contract between implementers and users of the interface. The users/consumers require that all the methods be implemented. First, ask yourself if your implementation without these methods is still useful. If so, ask yourself if you need to inherit from this interface at all.

If after this reflection, you still have valid reasons to implement this interface without implementing all the methods, you can create stub methods:

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

or, more dangerously, but possibly less disruptively:

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

This is an ideal scenario for Interface segregation. Please refer this design principle here (oodesign.com/interface-segregation-principle.html) You are require to segregate the contracts, don't put all eggs in one basket.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM