Блог

У меня есть интерфейс IKey , в котором я хочу иметь метод, который будет возвращать ключ в виде строки. Мы рассмотрели такой метод, как этот:

 String GetAsString();
  

который вернул бы строковое представление, но хотел бы иметь возможность снова объявлять ToString() в интерфейсе, чтобы заставить разработчиков реализовать его, но это не заставляет их, поскольку у них есть реализация, унаследованная от Object . Это было предложено:

 public interface IKey
{
    string ToString(string dummyParameter=null);
}
  

это приводит к принудительной реализации метода в любом реализующем классе, но из-за способа работы с необязательными параметрами вызывающим абонентам не нужно указывать значение для этого, и вы гарантируете, что любые вызовы ToString() метода для объектов, которые либо приведены в качестве интерфейса IKey , либо реализующего класса, всегда будут вызывать реализацию классаа не Object реализация.

В реализациях мы можем просто игнорировать dummyParameter и возвращать то, что мы хотим, в безопасности, зная, что вызов ToString() всегда будет на самом деле вызывать ToString(null) .

Теперь это кажется мне неправильным, но в то же время в этом есть что-то довольно приятное. Это почти то же самое, что иметь метод GetAsString() , поскольку его можно вызывать только в IKey интерфейсе и производных классах, за исключением того, что он выглядит как более естественный ToString() метод, который мы хотим использовать, и который мы можем принудительно реализовать в дочернем классе.

Сказав, что фиктивный параметр, который не используется, кажется неправильным.

Так это ужасно? Или отлично?

И подходит ли этот вопрос для SO или он должен быть для программистов?

Примеры

 public class Key :IKey 
    { 
        public string ToString(string abc = null) 
        { 
            return "100"; 
        } 
    }

Key key = new Key ();
Trace.WriteLine (key.ToString());
Trace.WriteLine (key.ToString(null));
Trace.WriteLine (key.ToString("ac"));
Trace.WriteLine (((object)key).ToString());
  

вывод:

 100
100
100
Blah.Tests.Key
  

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

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

С моей точки зрения, такой ToString() метод в пользовательском интерфейсе немного все испортил, потому что пользовательский интерфейс предоставил метод со стандартным и хорошо известным именем ToString() .

Я предпочитаю что-то более простое и очевидное, например:

 string KeyText { get; }
  

ИЛИ метод

 string ConvertKeyToString();
  

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

Идея добавления toString с параметром по умолчанию в интерфейс не слишком хорошо работает на практике. Разрешение перегрузки найдет toString без параметров при вызове без параметров (что, я должен сказать, кажется интуитивно понятным). Рассмотрим результат этой программы:

 void Main()
{   
    Console.WriteLine(new Key().ToString());
}

public interface IKey 
{
    string ToString(string dummy = null);
}

class Key : IKey 
{   
    public string ToString(string dummy) 
    {
        return "myspecialKey";
    }
}
  

Это выводит объект.Реализация toString() . Поэтому, если вы ограничены в использовании интерфейса, я бы назвал метод как-то иначе, чем toString() .

Переориентация

(IMO) — ToString() уже имеет очень четко определенную цель и значение. Вам может быть удобно перехватить его на основе имени, но, говоря, что это требуется, вы переназначаете то, чего не должны.

Ответ заключается в том, чтобы иметь свой собственный отдельный метод, первоначальную идею. Все остальное означает все .СЕТЕВАЯ документация о ToString() становится «неправильной».

Например, свойство тега является объектом во многих элементах управления пользовательского интерфейса. Возможно, вы хотите «пометить» элементы управления в какой-то галерее элементов управления. То, что имя подходит и тип подходит, не означает, что значение одно и то же, и вы можете ухватиться за него и изменить его назначение.

Именование

Я бы также предложил рассмотреть возможность изменения имени вашего интерфейса; если разработчики на самом деле не являются ключами? У меня создается впечатление, что они просто «привязаны» или имеют какой-то ключ, связанный с ними. В этом случае, IKeyed , IIndexed или что-то может быть лучше. Тогда a string Key { get; } становится более привлекательным. Возможно, проблема здесь в именовании.?

Я бы назвал это злоупотреблением из-за проблемы, на которую вы намекаете прямо здесь:

… и вы гарантируете, что любые вызовы метода toString() для объектов, которые либо приведены в качестве iKey интерфейса, либо реализующего класса, всегда будут вызывать реализацию класса, а не реализацию объекта.

Рассмотрим следующий код:

 IKey someKey = ...;
string keyAsString = someKey.ToString();
object someKeyAsObject = (object)someKey;
string keyAsString2 = someKeyAsObject.ToString();
  

Любой, кто смотрит на этот код, предположил бы, что keyAsString и keyAsString2 то же самое. Однако это будет вызывать разные методы, которые могут иметь разное поведение. Ик!

Ужасно, если мне нужно выбрать только одно слово… Запутанный и подозрительный более точно описал бы мою реакцию, если бы я столкнулся с этим в дикой природе.

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

Это, безусловно, было бы сюрпризом. Это исключает использование ожидаемого результата и использование ToString() без особых усилий. Тот факт, что нет никаких указаний на требуемые особые усилия, был бы «неожиданным» битом. Реализация по умолчанию ToString() в конечном итоге используется чаще, чем я ожидал. Я бы не стал запрещать или искажать его использование, если бы у меня не было другого разумного способа решить проблему.

Я не думаю, что это было бы «более естественным», чем хорошо названный метод / свойство, которое еще не является членом object .

Только что наткнулся на это. Как насчет того, чтобы интерфейс наследовал IFormattable?

http://msdn.microsoft.com/en-us/library/system.iformattable.aspx

Я сам этого не делал, поэтому могу ошибаться, но, похоже, это позволяет использовать параметр format для ToString метода для вашего интерфейса. Обратите внимание, что вы по-прежнему не изменяете параметр без параметров ToString , что, я согласен с другими, не должно выполняться в интерфейсе, но вместо этого вы используете ToString(string format, IFormatProvider provider) с распознаваемым форматом ввода, который в основном означает «дайте мне описание этого объекта в контексте, который он реализует, что угодно». Очевидно, что для каждого реализованного класса потребуется кодировать метод, но это только правильно.