Привет! В прошлой части серии статей про антипаттены мы разобрали списками основные элементы и кратко описали их. Давайте в этой части посмотрим на пять самых популярных антипаттернов, установим причины их возникновения и варианты решения. (Антипаттерны идут не в порядке популярности или частоты использования, просто рандомный порядок)
1. Магические числа
Возможно, наиболее часто встречаемый антипаттерн, особенно у новичков, хотя лично я видел данное нарушение и у мидлов. Для начала разберемся, что это такое; магические числа - это числа, которые не несут очевидного значения, смысловой нагрузки. Если вы, допустим, увидите следующий код: wheel.size += 0.25f, то очень сомневаюсь, что кто-либо из читающих поймет, что такое [0.25f] и почему именно на такое значение мы увеличиваем размер колеса. Это наглядный пример антипаттерны магические (волшебные) числа, старайтесь избегать его. Как правило он появляется когда программист ленится, но в таком случае хотя бы комментарии оставляйте, а то вашу работу еще другим людям рефакторить, сохраните им нервы.
2. Одиночество
Одиночество или синглтонизм - антипаттерн, который проявляется в виде чрезмерного злоупотребления паттерном/шаблоном синглтон (Singleton), который как бы указывает на то, что объект, использующий таковой паттерн, является единственным на, допустим, сцене. Как правило, паттерн синглтон учат в первую очередь, так как он очень прост. Но затем начинается ад, новички или разработчики, которые только начали изучать шаблоны проектирования, суют этот синглтон везде. Особенно весело становится, если потом в пайплайн разработки добавляется этап интеграции сетевой игры/мультиплеера. В чем проблема: если злоупотреблять синглтонизмом, то может возникнуть ситуация, при которой на сцене, например, есть несколько одновременно функционирующих сущностей, каждая из которая реализована при помощи паттерна Singleton. В таком случае, при попытке обратиться напрямую к экземпляру класса через свойство инстанциации от синглтона, произойдет коннект только с одним из всех объектов. Как правило, синглтон реализуют для действительно уникальных сущностей, например GameManager или WeatherController. (хотя насколько я знаю, менеджеров по-моему не очень любят в том же юнити).
3. Божественный объект
Антипаттерн, который хранит в себе слишком много данных и/или выполняет слишком много функций. В модульном программировании принято разделять сущности по функциональности. Если у вас есть класс PlayerState, то он должен отвечать исключительно за состояние игрока, а не весь его функционал в целом. Подход "божественного объекта" полностью противостоит этой идеологии. В ином случае, вместо того, чтобы объекты общались друг с другом, они будут полностью опираться и полагаться на этот самый божественный объект. Более того, в таких сущностях как правило невозможно поддерживать код в чистоте и порядке, следить за читабельностью и иерархией реализации функциональности, а данные просто теряются.
4. Спагетти-код
Плохо спроектированная, запутанная, сложная, неструктурированная для понимания программа. А если там еще и куча операторов goto, то можете вешаться. Антипаттерн так назван, потому что ход выполнения программы похож на миску спагетти, извилистый и запутанный. Любое злоупотребление или в целом использование оператора goto, а также тонна взаимосвязей и зависимостей является признаком данного антипаттерна. Наверное, это самый популярный вид ошибки в проектировании.
5. Таинственный код
Особенно любим, по-моему, JS разработчикам, которые любят сокращать все на своем пути. Это антипаттерн, который получается вследствие сокращений, использований аббревиатур и иных искажений названий членов сущности или самой сущности. Иногда кстати этим грешит даже C# , у которого есть библиотека System.IO, что означает Input-Output. Это, конечно, знают почти все опытные разработчики, но если вы впервые увидите эту аббревиатуру, то сходу будет сложно понять, за что она отвечает.
Итоги
Резюмируя, мы с вами разобрали самые популярные антипаттерны в программировании, часть из них классифицируются как ООП антипаттерны, а часть как антипаттерны кодирования. Я надеюсь, что я смог донести суть и смысл, а также помог разобраться в причинах и признаках ошибок проектирования систем. Я не знаю, будет ли третья часть этой серии, но если у вас есть предложения или остались вопросы без ответов, смело задавайте их в комментариях, а я с радостью на все отвечу!
Мой телеграм:https://t.me/nikita_kirakosyan_it. Здесь бывает эксклюзив.