Задать вопрос

Как правильно организовать написание классов PHP?

Добрый день.
Есть таблица с пользователями и два класса: users и user.
В users содержатся статичные методы: create(), delete(), update(), т.д.
Если можно так сказать, "глобальные" методы для управления данными в таблице. Есть, например, метод для удаления юзеров, которые были неактивны последние две недели. Экземляров класса users нигде не создается, сам класс используется только для инкапсуляции логики.
Экземляр класса user создается при каждой загрузке страницы и отвечает за авторизацию юзера на сайте, получение информации (ник, аватар, и т.д.)

1. Правильно ли так организовывать код?
Или наследовать user от users? Или иметь один класс, комбинирующий в себе статичные и публичные методы? Но тогда при каждой загрузке страницы и создании класса user будут объявляться статичные методы, которые нужны, возможно, крайне редко (скажем, то же удаление юзеров по крону запускается). Понятно, что это экономия на спичках, но проект нагруженный и хочется лаконичности.
2. Юзеры на сайте логинятся по OpenID, метод для обновления инфы по юзеру относится к user или к users? Как вообще определяете куда отнести тот или иной метод в таких неоднозначных ситуациях?
Или правильнее обьявить статичный users::update($id) и вызывать его в контексте $user как users::update($this->id).
3. Вообще, поделитесь своим опытом, как реализуете такие вещи и как правильнее.
Просто все это встречается достаточно часто: товары, категории и т.д., в которых нужен рычаг для управления конкретным объектом, и в то же время возникает необходимость делать множественные операции (скажем поменять родителя у child-категорий, и т.д.).
  • Вопрос задан
  • 3686 просмотров
Подписаться 5 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 3
на мой взгляд, проще создать экземпляр наследника класса user
например anonym (неавторизованный),
registered_user (авторизованный), ну и наверное admin(со всеми правами).
anonym может только создать пользователя или авторизоваться,
user может только редактировать себя или выйти с авторизации.
admin может все.
то есть класс user наследуют подклассы со своими методами доступа/управления к таблице пользователей.
Ответ написан
Комментировать
@lookid
Не изобретайте ООП. Лучше знать, как устроены Yii или Codeigniter, нежели писать свой костыль, который не имеет под собой никаких обоснований. Никому не нужны коленочные CMS-писатели. Тем более вы используете OpenID, стороннюю технологию, с которой не знакомы.
Ответ написан
Комментировать
@BoltovIgnat
Господа, сей вопрос и комментарии вызвал у меня интерес. И не смог не отвлечься от работы и написать что думаю. Первый суждение эти классы юзер энд юзерс, должны кому-то подчинятся т.е. быть в контейнере и глобальные методы над ними должны принадлежать ему. Закрадется резонный вопрос почему? Затем что у контейнера есть информация о всех полях и методах подчиненных элементов. И в окончании "Что бы лучше писать надо изучать парадигмы и патерны, а не фраймворки".
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы