В разработке программного обеспечения проблема йо -йо — это антишаблон , который возникает, когда программисту приходится читать и понимать программу, граф наследования которой настолько длинный и сложный, что программисту приходится постоянно переключаться между множеством различных определений классов, чтобы следить за потоком управления программы. Чаще всего это можно увидеть в контексте объектно-ориентированного программирования . Термин происходит от сравнения прыгающего внимания программиста с движением вверх-вниз игрушечного йо-йо . Тэнзер, Ганти и Подар описали проблему по названию, объяснив: «Часто у нас возникает ощущение, будто мы едем на йо-йо , когда пытаемся понять одно из этих деревьев сообщений». [1]
Большинство практик объектно-ориентированного программирования рекомендуют сохранять граф наследования как можно более мелким, отчасти для того, чтобы избежать этой проблемы. Использование композиции вместо наследования также настоятельно рекомендуется, хотя это все еще требует, чтобы программист держал в уме несколько определений классов одновременно.
Глубокие иерархии — это запах кода и симптом подклассификации для повторного использования кода . [2]
В более общем смысле проблема йо-йо может также относиться к любой ситуации, когда человеку приходится постоянно переключаться между различными источниками информации, чтобы понять какую-то концепцию.
Существует несколько методов рефакторинга кода , позволяющих сгладить эти иерархии, не нарушая общего поведения.
Методы объектно-ориентированного проектирования, такие как документирование уровней иерархии наследования, могут уменьшить влияние этой проблемы, поскольку они собирают в одном месте информацию, которую программисту необходимо понимать.