47 подписчиков
Дженерики очень опасная штука
Эххх, помню я несколько лет назад, когда в коде у меня ещё были всякие мысли типа "ух как я придумал" и когда было желание писать "красивые конструкции". Сколько я весьма странных вещей строил на дженериках. Я не люблю и почти не используют дженерики. Нет, конечно мы все используем дженерики в сетевых методах, во всём что связано с десериализацией, с коллекциями (типа объектного пула). Но дженерики чаще зло.
Но почему? Ведь удобно реализацию определять ниже по иерархии вызовов нежели делать это в самом классе, если есть такая возможность. И у меня тогда встречный вопрос. А чем это отличается от: Object, абстрактного класса и интерфейса? (как можно понять варианта три из-за параметров аля where) За исключением того, что их вы можете конкретизировать и определить на любом шаге и в любом уровне иерархии? Выигрыш в производительности на дженериках без кастов обжекта к конкретному типу конечно будет, но тем не менее
Проблема не в самих дженериках, а в том какой соблазн возникает их использовать там, где это не надо. Есть ещё такая проблема "а правильный ли код я пишу?". Когда программисты переживают "а пишет ли так кто-то, а корректно ли это?". Мне кажется из-за этого сложилась какая-то абсолютная нелюбовь к операторам as или is в коде. Так как в одно время их было как-то не модно юзать, и что код плохой если приходится так что-то определять. Но никого не смущало, что с архитектурной точки зрения дженерики — это ровно тоже самое по своей сути)
А что же лучше дженериков? Да почти всегда интерфейсы. Там конечно тоже свои нюансы, и если ответственность вашего класса манипулировать какими-либо ссылками и больше ничего не делать, то хороший вопрос зачем тут конкретизировать интерфейс, а не делать совсем абстрактно? Потому что переиспользование кода — это красивый миф. Особенно всяких супер абстрактных конструкций. Не потому, что это невозможно. А потому что очень долго реально проектировать что-то, что будет применимо в контексте любой системы. А в рамках одной долго разрабатываемой системы — это бывает очень опасно, так как изменения одного объекта прошивают вообще всю систему, что ведёт стабильно к неочевидным багам и техдолгу. Ведь это же тоже в некотором смысле связывание и централизация кода, только логикой поведения какого-то модуля. И в огромном проекте не всё можно покрыть тестами и заметить. А сейчас уже не нужно так экономить память устройства, чтобы ещё 1кб кода был проблемой :)
2 минуты
2 ноября 2022