Вы правы, это запах кода, и все скажут вам, что это baaaad.
Так что здесь я предлагаю скорее сделать самооценку серьезности проблемы:
У вас есть классы со многими геттерами и сеттерами ?
Ваши статические функции похожи на приведенные ниже?
Если да, попробуйте переместить логику в классе MyClass, что будет уже намного больше ОО. Это классическая ошибка в мире процедур / сценариев.
static void myMethod( MyClass anObject )
{
// get value from anObject
// do some business logic
// set value of anObject
}
Есть ли у вас много глобальных состояний , таких как данные, которые вы извлекаете из текущего сеанса?
Если да, сделайте оценку, хотите ли вы изменить его. ОО-способ - передать сеанс по цепочке вызовов. Но на практике удобно обращаться к сеансу как к глобальному объекту. Но это затрудняет тестируемость. Попробуйте удалить глобальное состояние и превратить его в обычный объект, который вы передаете и манипулируете в методах.
Сделайте эту оценку и попытайтесь определить служебные классы, сервисы классы и бизнес-объекты . Служебные классы - это вспомогательные классы с служебными методами (например, форматированием, преобразованием и т. Д.), Которые могут быть статическими. Класс обслуживания выполняет некоторую бизнес-логику, но он не должен иметь состояния и достаточно одного экземпляра. Бизнес-объекты user, products, article и т. Д. - это то место, где вы должны сосредоточить свои усилия. Попробуйте превратить обычные данные в объекты с некоторым поведением.
Взгляните на , если сущность немая . Даже если это для Java, концепции являются общими.
EDIT
Вот мой анализ, основанный на вашем комментарии:
- У вас нет доменной модели с сущностями. Вы управляете базой данных напрямую.
- То, что вы называете своей моделью, это то, что я называю услугами , и где вы выполняете бизнес-логику, которая манипулирует данными. Классы обслуживания без сохранения состояния , что является правильным. Как вы указали в вопросе, вам нужно либо постоянно создавать их заново, создавать один глобальный экземпляр или использовать статические методы.
Парадигма ОО говорит, что вы должны попытаться создать модель предметной области, в которой вы сопоставляете свою базу данных с сущностями. По крайней мере, модель анемичного домена , где сущности представляют собой скучный контейнер данных, который загружается / сохраняется в базе данных. Тогда парадигма ОО также говорит, что, если это возможно, нужно добавить немного логики в сущности.
Также было бы сказано превратить сервисы в объекты, чтобы упростить компоновку и повторное использование. Если бы это было так, вы могли бы, например, обернуть все сервисы перехватчиком для запуска / остановки транзакций или сделать некоторую проверку безопасности, которую вы не сможете сделать статическими методами.
То, что вы описываете (без юридических лиц + процедурные услуги без сохранения состояния), не считается отличным проектом ОО. Я бы предложил вам ввести модель анемичного домена как минимум и DAO . Что касается бесполезных процедурных сервисов, то на самом деле это реальность многих веб-приложений - если вам не нужно больше, вы можете придерживаться этого.
Мои 2 цента