Принудительно использовать подклассы интерфейса для реализации ToString

Question

Допустим, у меня есть интерфейс IFoo, и я хочу, чтобы все подклассы IFoo переопределяли метод ToString объекта. Это возможно?

Простое добавление сигнатуры метода в IFoo как таковое не работает:

interface IFoo
{
    String ToString();
}

, поскольку все подклассы расширяют Object и обеспечивают реализацию таким образом, поэтому компилятор не будет жаловаться на это. Есть предложения?

Answer 1

Я не верю, что вы можете сделать это с помощью интерфейса. Вы можете использовать абстрактный базовый класс, хотя:

public abstract class Base
{
    public abstract override string ToString(); 
}

Answer 2

abstract class Foo
{
    public override abstract string ToString();
}

class Bar : Foo
{
    // need to override ToString()
}

Answer 3

Jon & Andrew: этот абстрактный трюк действительно полезен; Я понятия не имел, что вы можете закончить цепочку, объявив ее абстрактной. Приветствия:)

В прошлом, когда я требовал переопределения ToString () в производных классах, я всегда использовал шаблон, подобный следующему:

public abstract class BaseClass
{
    public abstract string ToStringImpl();

    public override string ToString()
    {
        return ToStringImpl();
    }    
}

Answer 4

Я знаю, что это не отвечает на ваш вопрос, но, поскольку нет способа сделать то, о чем вы просите, я подумала, что поделюсь своим подходом, чтобы другие могли его увидеть.

Я использую гибрид предложенных Марком и Эндрю решений.

В моем приложении все доменные сущности происходят от абстрактного базового класса:

public abstract class Entity
{
    /// <summary>
    /// Returns a <see cref="System.String"/> that represents this instance.
    /// </summary>
    public override string ToString()
    {
        return this is IHasDescription
                   ? ((IHasDescription) this).EntityDescription
                   : base.ToString();
    }
}

Сам интерфейс определяет только простой метод доступа:

public interface IHasDescription : IEntity
{
    /// <summary>
    /// Creates a description (in english) of the Entity.
    /// </summary>
    string EntityDescription { get; }
}

Итак, теперь есть встроенный резервный механизм - или, другими словами, Entity, который реализует IHasDescription, должен обеспечивать EntityDescription, но любой Entity все еще может преобразовывать в строку.

Я знаю, что это в корне не отличается от других решений, предлагаемых здесь, но мне нравится идея минимизации ответственности базового типа Entity, так что реализация интерфейса описания остается необязательной, но вы вынуждены фактически реализовать метод description, если вы реализуете интерфейс.

ИМХО, интерфейсы, которые реализуются базовым классом object, не должны "считаться" как реализованные - было бы неплохо иметь для этого опцию компилятора, но, ну да ладно ...

Answer 5

Реализация метода интерфейса неявно запечатывает метод (а также переопределяет его). Итак, если вы не укажете обратное, первая реализация интерфейса завершает цепочку переопределения в C #.

Essential .NET

Абстрактный класс = твой друг

Проверьте этот вопрос

Answer 6

Извините, что похоронил эту старую нить из могилы, тем более что наш дорогой @ jon-skeet уже дал свой ответ .

Но если вы хотите сохранить интерфейс и не использовать абстрактный класс, я думаю, это все еще возможно, если ваш интерфейс реализует интерфейс System.IFormattable .

interface IFoo : IFormattable
{
}

Единственное, что нужно иметь в виду, чтобы правильно реализовать этот IFormattable, конкретная реализация также должна перезаписать Object.ToString().

Это ясно объяснено в этом хорошем посте.

Ваш конкретный класс теперь похож на

public class Bar : IFoo
{
    public string ToString(string format, IFormatProvider formatProvider)
    {
        return $"{nameof(Bar)}";
    }

    public override string ToString()
    {
        return ToString(null, System.Globalization.CultureInfo.CurrentCulture);
    }
}

Надеюсь, это еще может кому-нибудь помочь.

Answer 7

Я не думаю, что вы можете заставить любой подкласс переопределить любой из виртуальных методов базового класса, если эти методы не являются абстрактными.