公共静态方法+接口

Question

Since we can't define a public static method in the interface, can such an interface be implemented in a class with public static?

public interface IValidator
{
    bool IsValid(bool data);
}

public class MyValidator : IValidator
{
    public static bool IsValid(string data)
    {
        //code which returns bool
    }
}

Answer 1

No, C# does not allow for static interfaces.

Interfaces are designed to act as contracts between classes, that contract defines that each instance of these classes will have a set of method.

Jon Skeet has given a very good explanation in this question , I'd recommend reading it.

Answer 2

When you have an object instance, it makes sense to cast and use that as an interface. But when you work with static stuff, this isn't the case. You can only access static members through the name of the containing class, you can't pass them around like instances, etc.

It is possible to implement an interface and make sure it's not instantiated multiple times, it's called the singleton pattern. A singleton class is similar to a static class, but it has an instance that can be passed around and it can implement interfaces as well.

Answer 3

No, but you could get something close to it by having a static member return an instance of the interface.
Somthing like:

public class MyValidator : IValidator
{
    public bool IsValid(string data)
    {
        //code which returns bool
    }

    public static readonly IValidator Instance = new MyValidator();
}

Then you could use it in a static sort of way:

bool isValid = MyValidator.Instance.IsValid("data");

Answer 4

You cannot define static members via the interface, so if static members are required by design they can only be added to concrete types.

This ultimately produces a lot of confusion. Any other implementation would not have that same member. Mocked instances will not have access to that member. And so on.

Solution is to avoid declaring static members. In your particular case, I would object to the very design of the interface. I would prefer to see classes implement some interface like IValidatable:

public interface IValidatable
{
    bool IsValid();
}
...
public class SomeBoolClass: IValidatable
{
    private bool Data;
    public bool IsValid()
    {
        return this.Data; // i.e. return Data == true
    }
}
...
public class SomeStringClass: IValidatable
{
    private string Data;
    public bool IsValid()
    {
        return !string.IsNullOrEmpty(this.Data);
    }
}

In this way you obtain fully polymorphic validation across all current and future types.

If you insist on having a validator which receives low-level data (such as Boolean or string) to validate, then you are half-way doomed. Suppose that there are two classes which wrap string data. These two classes would normally have to be validated in different ways. But validator would not be able to distinguish which validation algorithm to apply based on input data. Even worse, validator would have to contain all validation logic for all types, existing and those yet to be coded. This means that validator would act as one giant (and inherently incomplete) switch statement.