Ответ 1
До тех пор, пока вы не злоупотребляете им, duck typing, как это, является частью причины dynamic
, добавленной к языку.
Мой вопрос заключается в том, следует ли, что следующее следует использовать ключевое слово dynamic
в С# 4.
У меня есть вспомогательные методы, которые обеспечивают более полезное представление различных объектов, чем их стандартные методы ToString
, которые я использую для модульного тестирования. Вот упрощенный пример:
public static string PrettyPrint<T>(IEnumerable<T> list)
{
return string.Join(", ", list);
}
// Needed because string is IEnumerable<char>, to prevent
// "Hello" -> "H, e, l, l, o"
public static string PrettyPrint(string s)
{
return s;
}
public static string PrettyPrint(object o)
{
return o.ToString();
}
Я использую их примерно так:
public static void PrettyPrinting()
{
object[] things = { 1, "Hello", new int[] {1, 2, 3} };
foreach (dynamic item in things)
{
Console.WriteLine(PrettyPrint(item));
}
}
Это приводит к следующему выводу:
1
Hello
1, 2, 3
Обратите внимание, что если я заменил ключевое слово dynamic
на object
, я получаю следующее (все вызовы маршрутизируются через PrettyPrint(object)
), чего я пытаюсь избежать:
1
Hello
System.Int32[]
Итак, мой вопрос в основном заключается в том, что это запах кода или законно ли таким образом отбрасывать object
до dynamic
?
До тех пор, пока вы не злоупотребляете им, duck typing, как это, является частью причины dynamic
, добавленной к языку.
Не ответ на конкретный вопрос, но я бы сказал, что ваш код не очень OO, это еще один запах.
В идеале вы хотите вызвать item.PrettyPrint()
, и каждый элемент должен вернуть свое представление и переопределить PrettyPrint
.
К счастью, существующие типы могут быть расширены с помощью методов расширения. Они позволяют вам добавлять методы и то, что я буду делать вместо этого.
Если вы все еще хотите иметь логику отображения каждого типа в одном классе, я бы объединил методы расширения с шаблоном .
Тем не менее, у меня нет среды С#, поэтому я не могу проверить, что предлагаю. Дайте мне знать, если вы попробуете это, и если это сработает.
Что касается вашего вопроса, я не уверен на 100%, так как не знаю стиль вашей команды в кодировке. (Я также вижу небольшие комментарии;))
DuckTyping использует его - однако разработчик должен знать, что они делают, прежде чем использовать его. В противном случае он, как работает с ножницами; его можно было бы злоупотреблять, как и другие ключевые слова в системе С#.
Лично я предпочел бы использовать методы расширения, но в зависимости от разработчика, его аргументов и документации, которые я, вероятно, допустил бы.
Самая большая причина моего колебания (и этот пример довольно приручен для некоторых из тех, что я видел онлайн), это мешает вам находить проблемы во время компиляции. Это требует более тщательного тестирования QA, намного более граничного тестирования и имеет более высокий риск отказа.