155 подписчиков
Антипаттерн GOD Object
Разными путями мы можем придти к тому, что в оном классе, модуле, сервисе собирается слишком много функционала, много данных и все остальные зависят от этого модуля или сервиса. Мы имеем страшную базу, big-models и много чего ещё в одном сервисе.
При этом:
- Крайне высокая степень связанности (coupling), при том не только на уровне межсервисного взаимодействия, но и внутри кода божественного сервиса.
- Объект содержит несвязанные функции и данные, превращаясь в "свалку" логики. (Low-Cohesion)
- Наличие BIG_моделей, в которую складываются все знания о мире в этой информационной системе по совсем не очевидной логике,
- Как следствие - сложность тестирования и развития. Последние может выражаться даже в нереально низкой скорости погружения разработчиков в задачи.
Как же так получилось?
- Нарушение принципа единственной ответственности: Объект занимается множеством совершенно разных задач, что приводит к избыточной сложности.
- Плохая архитектура: Когда проект не структурирован должным образом, и все компоненты сводятся к одному объекту, чтобы избежать создания дополнительных классов и связей между ними.
- Отсутствие хорошего планирования: На начальных этапах разработки может не быть четкого представления о том, как будет распределяться ответственность между объектами, и это приводит к тому, что один объект растет и становится слишком сложным.
- Низкий уровень инкапсуляции: Когда объект обрабатывает данные из разных частей системы, но не скрывает их детали, создавая зависимость между различными частями программы.
- Технический долг: Часто GOD Object появляется из-за ускоренной разработки или избыточной экономии на архитектурных решениях, что со временем приводит к накоплению сложных и неуправляемых компонентов.
1 минута
10 февраля