Это в порядке для доведения использующих главным образом статических классов?
Я в настоящее время переписываю электронный магазин - но только сторона клиента, т.е. CMS остается главным образом в такте. Я не использую предварительно созданную платформу, поскольку система должна сохранить назад совместимость с CMS, и у меня должна быть полная свобода структуры кода.
Новой системой является просто базирующийся MVC, и у меня есть Bootstrapper, который загружает контроллеры на основе текущего uri и последних моделей использования для реальной работы - и с сессиями и с базой данных.
tl; доктор It является моим первым проектом без предварительно созданной платформы.
Я очень неопытен когда дело доходит до шаблонов разработки. Я знаю, как делают большую часть популярной работы, но, никогда не имели не вводит их в эксплуатацию.
Теперь я подозреваю запахи кода, потому что все мои модели являются классами, которые состоят просто из статических методов. Я не могу найти преимущества выполнения их другим способом. Мне обычно нужны некоторые методы в различных местах через код. Т.е. Я должен выбрать зарегистрированного пользователя в основном расположении, проверить пользовательские права видеть текущую страницу в bootstraper, панели пользователя дисплея контроллером. Я должен был бы повторно инстанцировать объекта каждый раз или сохранить глобальный, если бы я не использовал помехи. Также не будет потребности больше чем в одном таком классе за один раз.
Я должен пропускать что-то, потому что даже при том, что я использую ООП, некоторые мои классы являются просто бессмысленными контейнерами для своих методов (и иногда несколько частных переменных). Я, возможно, просто использовал PHP4 и простые функции.
Любые комментарии или совет высоко ценились бы.
Править: несмотря на все эти образованные ответы, я остаюсь при своем мнении. Даже при том, что это по всей вероятности из-за моего отсутствия опыта, я все еще не предвижу ничего идущего не так, как надо с текущей установкой. Я подразумеваю, что даже не понимаю ситуацию, где у меня были бы любые неудобства из-за архитектуры кода, как это теперь. Я надеюсь, что не получаю резкий урок, когда слишком поздно для изменения чего-либо...
7 ответов
Вы правы, это запах кода, и все вам скажут, что это баааад.
Итак, здесь я предлагаю скорее провести самооценку серьезности проблемы:
Есть ли у вас классы с большим количеством геттеров и сеттеров ?
ваши статические функции , подобные приведенной ниже?
Если да, попробуйте переместить логику в класс
MyClass, который уже будет более объектно ориентированным. Это классическая ошибка процедурного мира / мира сценариев.
static void myMethod( MyClass anObject )
{
// get value from anObject
// do some business logic
// set value of anObject
}
У вас много глобального состояния , например данных, которые вы извлекаете из текущего сеанса?
Если да, оцените, хотите ли вы это изменить. Объектно-ориентированный способ - передать сеанс по цепочке вызовов. Но на практике удобно обращаться к сеансу как к глобальному объекту. Но это затрудняет проверку. Попробуйте удалить какое-то глобальное состояние и превратить его в обычный объект, который вы передаете и управляете в методах.
Сделайте эту оценку и попытайтесь идентифицировать классы полезности , классы служб и бизнес-объекты . Служебный класс - это вспомогательные классы с служебными методами (например, форматирование, преобразование и т. Д.), Которые могут быть статическими. Класс обслуживания выполняет некоторую бизнес-логику, но они не должны иметь состояния, и достаточно одного экземпляра. Бизнес-объекты: пользователь , продукты , статья и т. Д. - вот где вы должны сконцентрировать свои усилия. Попробуйте превратить простые данные в объекты со встроенным поведением.
Взгляните на , если объект должен быть тупым . Даже если это для java, концепции общие.
РЕДАКТИРОВАТЬ
Вот мой анализ, основанный на вашем комментарии:
- У вас нет модели предметной области с сущностями. Вы напрямую управляете базой данных.
- То, что вы называете своей моделью, я называю службами , и именно здесь вы выполняете бизнес-логику, которая манипулирует данными. Классы обслуживания не имеют состояния , что верно. Как вы указали в вопросе, вам нужно либо постоянно воссоздавать их, либо создавать один глобальный экземпляр, либо использовать статические методы.
В объектно-ориентированной парадигме говорится, что вы должны попытаться создать модель предметной области, в которой вы отображаете свою базу данных с сущностями. По крайней мере, иметь анемичную модель предметной области , в которой сущности представляют собой скучный контейнер данных, которые загружаются / сохраняются в базе данных. Тогда парадигма объектно-ориентированного программирования также говорит, что нужно добавить немного логики в сущности, если это возможно.
Также можно сказать, что нужно превратить сервисы в объекты, чтобы упростить составление и повторное использование.Если бы это было так, вы могли бы, например, обернуть все службы перехватчиком для запуска / остановки транзакций или выполнить некоторую проверку безопасности, которую вы не сможете сделать с помощью статических методов.
То, что вы описываете (отсутствие сущностей + процедурные услуги без сохранения состояния), не считается отличным объектно-ориентированным дизайном. Я бы посоветовал вам представить хотя бы модель анемического домена и DAO . Что касается процедурных сервисов без поддержки, то это на самом деле реальность многих веб-приложений - если вам не нужно больше, вы можете придерживаться этого.
Мои 2 цента
Краткий ответ: Ничего страшного, но вы отказываетесь от преимуществ ООП.
Одним из аргументов в пользу использования объектов является то, что большую часть времени существует более одного типа объектов, которые выполняют роль. Например, вы можете поменять местами объект доступа к данным DBVendor1 на объект доступа к данным DBVendor2, имеющий тот же интерфейс. Это особенно удобно, если вы используете модульные тесты и вам нужно поменять местами объекты, которые действительно работают, с фиктивными объектами (макетами и заглушками). Думайте о своих объектах с тем же интерфейсом, что и о кубиках Lego разного цвета, которые подходят друг к другу и легко взаимозаменяемы. А со статическими объектами этого просто не сделать.
Конечно, повышенная гибкость объектов имеет свою цену: инициализация объектов и их объединение - это больше работы (как вы писали) и приводит к большему количеству кода и объектов, которые объединяют другие объекты. Здесь в игру вступают такие шаблоны проектирования, как builder и factory .
Если вы хотите пойти по этому пути, я советую вам прочитать о внедрении зависимостей и использовании инфраструктуры DI .
Вы можете заметить одну вещь: если вы планируете проводить какое-либо модульное тестирование с использованием имитации / заглушки, вам, вероятно, придется нелегко из-за статических классы и методы нелегко имитировать, заглушать или тестировать.
Статические методы имеют свои преимущества. Одна из них заключается в том, что, поскольку вы не можете унаследовать их, они работают лучше. Но использование их всех времен ограничивает вас. Вся парадигма ООП основана на возможности повторного использования базовых классов с использованием наследования.
Если вы в основном используете только статические классы, вы действительно исключили объект из объектно-ориентированного программирования. Я не говорю, что вы делаете что-то неправильно, я говорю, что, возможно, ваша система не должна поддаваться ООП. Возможно, это простое приложение, требующее некоторых основных служебных функций (отправка электронной почты и т. Д.). В этом случае большая часть вашего кода становится очень процедурной.
Если вы имеете дело с базами данных, у вас может быть статический класс db и простой бизнес-уровень, и ваше приложение php взаимодействует с вашим бизнес-уровнем, который, в свою очередь, взаимодействует с уровнем вашей базы данных. Это становится вашей типичной трехуровневой архитектурой (некоторые люди называют ее четырехуровневой и отделяют фактическую базу данных от уровня данных, то же самое).
Если вы на самом деле не вызываете методы, которым требуется объект, а не в чем смысл всех этих статических классов, просто вопрос, который следует задать себе.
Я бы с осторожностью относился к использованию статических переменных и классов в веб-приложениях. Если вам действительно нужно разделить экземпляр между пользователями, то вполне можно обойтись одним экземпляром (см. шаблон проектирования "Singleton").
Однако, если вы пытаетесь сохранить состояние на разных страницах, вы должны сделать это либо с помощью ViewState, либо с помощью объекта Session.
Если у вас будет глобальная статическая переменная, то может возникнуть ситуация, когда одновременные пользователи будут бороться за обновление одного и того же значения.
Технически в этом нет ничего плохого. Но практически вы теряете многие преимущества объектно-ориентированного программирования. Также пишите код/функциональность там, где ей место. Например:
user.doSomeTask()
на пользовательском объекте имеет больше смысла, чем
UserUtils.doSomeTask(User user)
Используя концепции ООП, вы абстрагируете функциональность там, где ей место, и в будущем это поможет вам изменить код, расширить функциональность легче, чем использование статических методов.