Python Development
17.01
Python и утки. Когда тип не важен
Разберемся с термином — duck typing. Представь себе, что ты на озере и видишь утку. Ты же не спрашиваешь её документы, чтобы понять, утка ли это? Ты её видишь, слышишь, она "крякает", ходит как утка и вообще ведет себя, как утка, значит, это утка. Все просто, правда?
Вот так и в Python, только здесь у нас не утки, а объекты. В Python нет строгой типизации, как, скажем, в Java или C++, где ты должен заранее указать тип переменной. В Python тебе достаточно того, как объект ведет себя, а точнее — какие методы или атрибуты у него есть. Ну, а теперь разберемся, как это влияет на код.
Представь ситуацию, ты пишешь функцию, которая ожидает некий объект, который должен уметь "крякать", то есть иметь метод quack(). Тебе не нужно проверять, что это именно утка, достаточно того, что объект умеет "крякать". Вот это и есть duck typing.
Ты скажешь, а что если объект не будет крякать? Ну, ты же не хочешь, чтобы всё полетело к чертям, правильно? Да, тут есть подводные камни. Если объект не будет иметь нужного метода, Python просто взорвёт твою программу с ошибкой, и ты останешься с разбитым кодом и мыслями о том, как ты мог на это не обратить внимания. Но с другой стороны, это даёт гибкость и меньше ограничений. Ты можешь легко работать с различными типами, пока они ведут себя нужным тебе образом.
Ты хочешь сделать функцию, которая принимает объект, и если он умеет "плавать" (метод swim()), то она его "пустит на воду". В идеале это может быть утка, но почему бы не сделать её универсальной, чтобы её можно было использовать с любым объектом, который умеет плавать? На изображении то как это будет работать в Python.
Вот смотри, никаких проверок типа, никакой жесткой типизации. Мы просто проверяем, что объект умеет делать, а не кто он по сути. И если объект не умеет плавать, то... ну, Python тебе об этом обязательно скажет, когда ты попытаешься вызвать swim() у него. Если этого метода нет, ты получишь ошибку и будешь вынужден всё исправить.
Так что duck typing — это когда ты доверяешься тому, что объект делает, а не тому, кто он есть. Это упрощает код, делает его гибким, но требует от тебя быть внимательным, потому что ошибка может проявиться в самый неожиданный момент. Звучит как свобода, правда? Но, как и в любой свободе, тут есть свои риски. Порой лучше всё-таки убедиться, что объект делает именно то, что ты от него ждёшь, а не просто надеяться на его "плавучесть".
еще контент в этом сообществе
еще контент в этом соообществе
Python Development
17.01
войдите, чтобы увидеть
и подписаться на интересных профи