Что корректно выносить в отдельный класс для веба?

Question

[Rasmusen505]

Здравствуйте. Делаю учебный проект на php (опыт - около года) и уже во 2й раз меняю его архитектуру. Все дело в том, что я до конца не могу осмыслить, какие части, в данном случае, серверной части сайта нужно выносить в отдельный класс? Допустим, у меня на проекте есть 2 типа пользователей: администраторы и обычные юзеры, а также доска объявлений. Изначально я сделал для всех пользователей класс юзер, который отвечал и за регистрацию, и за авторизацию. В общем , за все, к чему относится пользователь (кроме БД и классы с лотами). И вот я почесал репу и подумал, что для авторизированного пользователя нужен свой класс, для регистрации - тоже, как и для методов проверки валидности данных при регистрации например.
В общем, я бы хотел научиться чувствовать и понимать, что действительно нужно выносить в отдельный класс, а что можно в качестве методов оставить в каком-то классе, сделав его побольше.
Заранее спасибо!

Comments

[Дмитрий]

Почитайте за solid

[Rasmusen505]

Дмитрий, я читал за солид, и я так понимаю, что вы это написали с акцентом на первую букву. Я потому и спрашиваю, что с одной стороны, для примера, регистрация - это как раз единственная ответственность , и инкапсулировать ее методы в класс юзер - получится нарушением этого правила, с другой стороны, мы регистрируем конкретно юзера и никого кроме, да и методов там, условно, 3, и стоит ли создавать ради них класс? Ведь в нем, навскидку, даже свойств не будет

[Кирилл Несмеянов]

Rasmusen505, а ОО не про свойства вообще, если на то пошло ;)

И вообще не про какие-либо поля. Скорее наоборот - наличие полей является неизбежным злом.

[FanatPHP]

Вынужден огорчить.
Научиться чувствовать по итогам поста на форуме невозможно. На это надо несколько лет

Но можно получить совет по отдельным классам. Но для этого надо задать вопрос. Без всей этой беллетристики, но с максимумом конкретики про классы. И подробным описанием, почему хочется разделить

[Дмитрий Беляев]

Почитайте за solid

главное не на русском...

[Rasmusen505]

FanatPHP, мне, к сожалению, ближайшее время не показать конкретные примеры.
Спасибо за ваш и Кирилл Несмеянов ответы, можно тогда попросить у вас порекомендовать источник, в котором приводятся более прикладные примеры, чем "давайте для наглядности создадим класс юзер где будет гетер сетер и деструктор"?
Просто, если перефразировать мой изначальный вопрос, то он звучит примерно так:
Насколько приемлемо МАКСИМАЛЬНО делить и дробить классы на более средние? Или, как я опять же привел в пример, будет нормально делать методы регистрации/валидации/Логина в одном классе User с методами а-ля "получить данные пользователя","редактировать аватарку"?
P.s. понимаю, что вопрос, возможно, задан абстрактно, но мне правда не найти в интернете на него ответа, вот и пытаюсь выяснить и более опытных людей напрямую. Ещё раз спасибо за ответы

[FanatPHP]

В том то и дело что нет таких примеров. Как сказал один умный человек, "архитектура - это то что нельзя нагуглить".

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

Читайте книжки - Мартина, Фаулера

[Кирилл Несмеянов]

Rasmusen505, геттер и сеттер про который вы говорите - это пример анемичных классов, который являются по факту антипаттерном в "чистом" ОО. Объекты - это поведение, а не данные.

Поэтому я и сказал, что данные - это неизбежное зло.

P.S. Хотя все эти тезисы/критерии являются понятием сугубо субъективным, потому что в реальном мире есть DTO, обязанность которых являться структурой и не предоставлять поведенческого АПИ.

Answer 1

[Валентин]

Rasmusen505,
Регистрация, авторизация это процессы, пользователь - это сущность.
Процесс может затрагивать много сущностей, сущность может участвовать во множестве процессов.
В случае авторизации в процессе может быть задействовано множество классов:
- Классы форм представлений (View), которые отрисовывают сами формы и биндят в них параметры модели формы.
- Классы моделей форм регистрации/аутентификации, которые так же могут и валидировать форму.
- Класс UserIdentity, реализующий интерфейс IIdentity отвечающий за аутентификацию пользователя.
- Класс пользователя, который часто и реализует интерфейс IIdentity.
- Классы контроллеров, которые обрабатывают запросы и находятся между представлением и моделями, например. Это если мы говорим об арзитектуре MVP.

Регистрация пользователя - это процесс, в котором может участвовать множество классов и делает он приблизительно следующее:
1) Получает от пользователя информацию о регистрационных данных (Класс представления и класс модели формы)
2) Валидация данных пользователя при отправке запроса на регистрацию (Контроллер получает от представления (View) информацию, создает модель(класс) User и выполняет сохранение)
3) Если в базе такой пользователь уже есть (проверка на уровне модели/СУБД на уникальность определенных полей), то контроллер от модели транслирует ошибки в класс формы и пользователь их исправляет.
4) Если все ок, то пользователю выдается сообщение об успешной регистрации (ответ от контроллера) и контроллер шлет ссылку о подтверждении регистрации по email (тут сохраняется токен привязанный к записи в таблице пользователей, нужен для генерации ссылки на подтверждение регистрации, по нему потом ищется нужный пользователь для его активации).
5) Далее уже другой контроллер или другой метод этого же контроллера обрабатывает ссылку и выставляет флаг через модель пользователя о том, что регистрация подтверждена.

Я думаю, что Вы путаете класс регистрации с моделью формы регистрации.
Тогда путаница в терминологии и ход мыслей правильный.