Антипаттерн №3 — Божественный объект (God Object)

Совсем недавно мной были рассмотрены два наиболее распространённых антипаттерна (антипаттерн — пример плохой реализации кода, проектирования etc.) — спаггети код и магические числа. Сегодня мы поговорим про почётное третье место — Божественный объект (англ.: God Object).

Во времена, когда только-только зарождалось понятие Web 2.0 (2000-2005) и фактически происходило становление динамического интернета — было почему-то модно писать свои сайты и системы на языке PHP. Одно время считалось мейнстримом организовать всю логику в одном файле. Только index.php в корне в котором и админ-панель, и фронтенд, и бекенд и генератор статической информации. Тогда это казалось прикольной идеей (я искренне считаю, что и сегодня это интересный вызов для одного программиста; такой себе личный челлендж, но сугубо как упражнение — не для прода). Так вот, данный гипер монолитный подход в некотором смысле и является олицетворением антипаттерна Божественный объект.

God object — это частая ошибка проектирования при объектно-ориентированном подходе, суть которой сводится в излишней концентрации важных функциональных составляющих программы в одном месте (отсюда и название). Данный объект и хранит в себе слишком много ответственностей, и покрывает слишком много задач и кейсов одновременно. Всегда нужно помнить, что основополагающая линия чистого и хорошего кода состоит в том, чтобы разделять большую задачу на как можно более мелкие функциональные кусочки. Этот модульный подход хорошо описан в книгах «Чистый код» Роберта Мартина и «Совершенный код» Стива Макконнелла, а также в главных принципах SOLID. Плюс ко всему мы все знаем, что функции должны выполнять только 1 конкретную задачу, а предметная область создаваемых объектов не должна выходить за рамки какой-то конкретной одной ответственности.

Божественный объект становится большим и неповоротливым для поддержания своего существования, вам приходится носится с ним в каждом закоулке программного кода: все узлы системы полагаются на него и жёстко с ним связаны. Поддерживать такой код становится труднее и труднее.

К слову, не только в ООП можно встретить божественные объекты. В процедурных языках также существуют божественные файлы, которые хранят состояние в слишком большом количестве локальных переменных и трудную структурную организацию иерархии методов. При особом умении и старании, божественным объектом можно сделать какую-то отдельно взятую процедуру (функцию или метод), но это уже будет считаться частным случаем спаггети-кода.

Перегружать логикой отдельный взятый объект, конечно, не смертельно. Возможно, что данный подход может даже быть хорошим выбором, если речь идёт о маленьких проектах без шансов на вырост — где важнее скорость. Также, в среде, где ограничены ресурсы — по памяти, процессору или дисковому IO, где поддерживаемость кода становится меньшим приоритетом перед вообще возможностью самой работы. Но это всё исключения подтверждающие правило. Не перегружайте ваши ответственности, помните про первую букву SOLID (Принцип единственной ответственности; англ. — The Single Responsibility Principle, SRP), не плодите сайдэффектов в функциях. Не заводите божественных объектов — будьте атеистами, ребятами! 🙂