Есть ли случай, когда вы написали что-то на таком языке (например, C#, Java) и пропущенную утку? (См. this question для аргументов против печати утинов)Аргументы для утиной печати на строго типизированном языке ООП?
Этот другой вопрос имел мало общего с утиным набором текста. Во всяком случае, если предположить, что это не закрывается, я бы сказал, что когда-то я очень скучаю по типу утки, когда пытаюсь тестировать классы с большим API. Нам нужна отдельная структура для создания издевательства над ними, в то время как на другом языке программирования вы, возможно, просто проходите в самостоятельном письменном классе, который реализует основные основы того, что вам нужно.
Например, попробуйте высмеять JDBC ResultSet в java без рамки, это немного боль.
Каждый раз, когда вам нужно работать с кодом, который у вас нет, и у которого нет правильной абстракции (HttpContext кто-нибудь?). Поскольку у вас не может быть метода, который вы принимаете IHttpContext, поскольку тип HttpContext не имеет такой абстракции, вам нужно установить адаптер и/или Factory и т. Д. Было бы очень приятно, если бы вы могли определить контракт IHttpContext в своем коде, сделать его похожим на HttpContext, настроить ваш метод для приема IHttpContext и иметь истинный, реальный объект HttpContext, который передается в IHttpContext.
Первый ответ, который я вижу :) – ripper234
вы должны выглядеть сложнее :) –
Никогда. Я использовал Java с 90-х и Python с 01 или около того.
Вот почему я никогда не пропускал утиную печать на Java.
«Утиная печать в Java-вопросе» действительно представляет собой абсолютную неспособность понять Полиморфизм. Если вы когда-нибудь думаете, что вам нужна какая-либо идентификация типа времени выполнения или функциональность «isinstance», вам не удалось понять Полиморфизм, и вы делаете это неправильно.
См. Вопрос Programmer Ignorance Pet Peeve. Неспособность понять полиморфизм - огромная проблема и приводит к ошибке «утка набрав в Java».
Если вы понимаете полиморфизм, вам не нужно вводить утиную печать, и вы не пропустите его при переключении между Python и Java.
В соответствующей заметке я использую только Python isinstance() как часть утверждения, чтобы сделать функцию, которая требует, чтобы целые числа взорвались, когда он получает нецелое число. isinstance() иногда используется с попытками на Java делать вещи, похожие на утки.
Дело в том, что я старый (52) и не очень умный. Поэтому я должен придерживаться иерархии классов «сильный-иш» в Python или меня путают. Я всегда оставлял пространство в проекте Python для реорганизации в более строгую иерархию классов, если это становится необходимым.
Использование isinstance - это не утка, на самом деле это подрывает утиную печать. класс A {метод foo() {...}} класс B {метод foo() {...}} function not_duck_typed (x) {if (x isinstance A) {x.foo()} } Функция duck_typed (x) {x.foo()} Тот, кто указывает на утиную печать, вы можете передать экземпляр A или B в duck_typed, несмотря на то, что они не имеют общего анкестора или формальный интерфейс. Утиная печать по-прежнему является полиморфизмом. –
Вы вводите в заблуждение идентификацию типа времени/isststance с утиным типом. В Java интерфейсы определены явно - в языках с утиным языком они определяются неспецифично методами, которые предоставляет объект. –
Наличие языка, выполняющего утиную печать на основе сигнатур метода, никогда не должно быть необходимым в ситуациях, когда язык пытается обойти слабость дизайна (как в случае с конструкцией C# foreach). С другой стороны, существует много ситуаций, когда было бы полезно сделать что-то похожее на утиную печать с помощью интерфейсов. Например, если у вас есть метод UseDuck, который принимает общий параметр, который ограничен для реализации интерфейсов IWalkLikeDuck и IQuackLikeDuck, код, который имеет переменную общего типа, которая ограничена для реализации как IWalkLikeDuck, так и IQuackLikeDuck, может передать ее UseDuck. Однако нет никакого хорошего способа сохранить код в форме, которая может быть передана в Wowzo после ее выхода.Было бы очень полезно, если бы можно было определить тип IWalkAndTalkLikeDuck, унаследованный от обоих других интерфейсов, но будет автоматически рассматриваться как реализованный любым классом, который реализует как IWalklikeDuck, так и ITalkLikeDuck, чтобы можно было хранить ссылку на любой тип, который знал о внедрении IWalkLikeDuck и ITalkLikeDuck в List<IWalkAndTalkLikeDuck>.
Предполагаю, вы имеете в виду статически типизированный, а не строго типизированный? – Kylotan
Килотан, нет, это было бы противоречиво. динамические <-> статические, сильные <-> слабые ортогональные. – Svante
Я знаю, это то, что я делал: формулировка вопроса подразумевает, что у строго типизированных языков нет утиного набора текста. Некоторые из них, т. Е. Python. – Kylotan