Тип утки как синтаксический сахар для размышлений: хорошая или плохая идея?
В последнее время я подумал, не было бы хорошей формой синтаксического сахара в таких языках, как Java и C#, включать тип «утка» в качестве типа параметра метода? Это выглядело бы так:
void myFunction(duck foo) {
foo.doStuff();
}
Это может быть синтаксический сахар для вызова doStuff () через отражение, или это может быть реализовано по-другому. Foo может быть любого типа. Если foo не имеет метода doStuff (), это вызовет исключение времени выполнения. Дело в том, что у вас будут преимущества более жесткой заранее заданной парадигмы интерфейса (производительность, проверка ошибок), когда вы захотите, то есть большую часть времени. В то же время у вас будет простой и понятный бэкдор, позволяющий уклоняться от набора текста, который позволит вам без значительного рефакторинга вносить изменения, не предусмотренные в первоначальном дизайне. Более того, он, скорее всего, будет на 100% обратно совместим и будет полностью соответствовать существующим языковым конструкциям. Я думаю, что это может помочь сократить чрезмерно продуманный стиль программирования на всякий случай, который приводит к запутанным и загроможденным API. Считаете ли вы, что что-то подобное будет хорошо или плохо для статических объектно-ориентированных языков, таких как C# и Java?
Ответы 3
Ключевое слово dynamic поддерживает эту точную семантику и будет в C# 4.0.
Однако это не только для размышлений. Это реализация динамическая отправка, которая использует отражение только в том случае, если другой механизм недоступен.
Этот вопрос также содержит много полезной информации.
Фактически, это очень похоже на «динамический» тип, который будет частью C# 4.
Мой короткий ответ: «Да, Duck Typing - это то, что было бы полезным инструментом для объектно-ориентированных языков. Команда C# соглашается и внедряет его в C# 4.0».
Длинный ответ:
У Duck Typing есть свои плюсы и минусы ... есть много людей, которые полностью отказываются от него, но я скажу вам, что: есть несколько очень веских причин для использования Duck Typing для задач, которые нельзя решить должным образом. в любом другом случае.
См. Мой пост об интерфейсе, который использовал словарь вместо IDictionary, где Duck Typing спас бы положение:
В C# есть НЕКОТОРЫЕ утиные типы, встроенные с 1.0! Возьмем, к примеру, ключевое слово foreach. Распространенное заблуждение, что ваш тип должен быть IEnumerable, чтобы использовать объект в цикле foreach. На самом деле оказывается, что это НЕ правда. Вам нужно только реализовать GetEnumerator (), и реализация интерфейса не является обязательной (хотя это хорошая форма). Это утиная машинка.
@supercat ты имеешь в виду вроде этого? github.com/skyguy94/dynamic-wrapper
Да, что-то в этом роде; одна вещь, которую я не заметил, - это наличие foo.As<T>.As<U> == foo.As<U>, которое было бы важной функцией для того типа интерфейса, который я хотел бы видеть.
Мне не нравится идея именования элементов типа "утка", но хотелось бы, чтобы существовал способ интерфейсов типа "утка" и их комбинаций [например, «этому методу нужно что-то, что есть
IEnumerable<Thing>иILookup<Thing, OtherThing>], и он позволяет интерфейсам объявлять, что другие конкретные типы должны считаться реализациями [с интерфейсом, который либо напрямую содержит код для реализации, либо указывает статический класс, который его содержит]. подход обеспечил бы «защиту от опечаток», сохранив при этом многие полезные аспекты динамической типизации.