Много-чего-делающий класс, модули (классы) которого должны производить проверку исходных данных

Разбивать ли логику на модули, которые могут работать изолировано (с проверкой данных внутри)?

  • да

    Голосов: 3 60,0%
  • нет

    Голосов: 0 0,0%
  • есть другой вариант

    Голосов: 2 40,0%

  • Всего проголосовало
    5

korpus

злой бобёр
Помогите разработать архитектуру класса или по крайней мере дайте совет как лучше делать надо в таких случаях.
Есть задача: получить данные от пользователя, сделать XML-документ, с помощью курла отправить его на сервер, получить в ответ другой xml-документ, распарсить его и вывести результат в браузер, создав для этого пейджинацию.

Для удобства использования, я считаю, что надо поместить всю логику в один класс. Так просто, т.к. не нужно подключать отдельные классы, а нужно подключить только отдельный файл пускай и с большим классом.
PHP:
$ar=array(); //массив с опциями, полученный от пользователя
$myclass=new myclass();
$myclass->set_param($ar); //в объект класса добавляю исходные данные
$result=$myclass->execute(); //вся логика скрыта внутри класса
Теперь в $result у меня в результатах содержатся данные, которые я могу обработать и вывести в браузер
По хорошему так делать не надо, т.к. это будет очень сложный класс. Преимущества помещения всей логики в один класс я вижу в том, что мне нет необходимости использовать отдельно модули, отвечающие за а) создание xml-документа, б) отправки запроса с помощью curl, в) парсинг xml-документа, полученного в ответе. Также у меня есть возможность один раз проверить все данные в массиве $ar на корректность, когда я передаю этот массив с помощью $myclass->set_param().

В то же время если я создам несколько классов в предположении, что а) это удобно б) классы можно будет использовать отдельно друг от друга как модули, то у меня появляется необходимость проверки исходных данных на корректность для каждого из этих модулей. Например, модуль, отвечающий за использование курла и отправки запроса на сервер должен получить какие-то данные для этого, а значит должен эти данные проверить-обработать, чтобы вместо например целого числа пользователь не отправил строку. Проверка данных, таким образом, должна производиться в каждом отдельном модуле: модуле отвечающем за создание xml-документа, модуле отвечающем за парсинг xml-документа, модуле отвечающим за curl и т.д. Я же хочу использовать модульность, а модули подразумевают то, что каждый из них проводит свою собственную проверку данных.
Если же забить на модульность и делать один сложный класс, то я просто все данные, полученные от пользователя, сохраню в одну переменную так
PHP:
class myclass
{
	$ar=array(); //здесь хранятся один раз проверенные данные
	function set_param($ar)
	{
		//здесь проверка всех данных из $ar
		$this->ar=$ar;
	}	

}
И теперь не нужно проводить проверку в каждом модуле, а всё собрать в одну кучу, так как ясно, что весь класс будет иметь дело только с корректными и один раз проверенными данными.

Получилось немного многословно, но хотел подробно описать проблему и хотел бы получить совет, как в таких случаях лучше создавать архитектуру.
 

Mols

Новичок
Слово паттерн вам наверное знакомо)))
Дык вот есть ещё и анти паттерны. То, что Вы хотите сделать получило вот такое описание

ИМХО всё это надо разбить на отдельные части.
Если проблема с валидацией структуры - делаете класс отвечающий за структуру и всё.
Передаёте этот класс между объектами.
Если же им надо валидировать разные части этой структуры в разных модулях, дык тогда вообще в чем вопрос?

Ну а в итоге, всё это скорее всего надо будет завернуть в отдельный класс сервис.
Который снаружи будет выглядеть так же целостно, как и "один большой класс".
 

korpus

злой бобёр
Mols,
а зачем эти классы плодить? Их же надо будет потом подключать, следить чтобы файл с классом в нужной папке находился и прочее.
Проблема в том, что каждый класс должен провести проверку входных данных. По сути все эти классы и делают то, что каждый из них проверяет одни и те же данные от пользователя на корректность. Это вообще нормально? Может вообще отказаться от проверки данных в каждом таком классе-модуле, посчитав, что данные уже раз проверены, а значит их не надо проверять? Но тогда получается и разбивать логику на классы нет необходимости :)
 

Mols

Новичок
korpus
Зачем, зачем... я ж грю... паттерн - лучшая практика. Анти паттерн, соответственно понятно какая практика. Это опыт огромного числа людей.

1. если нет нормального автолоада пропишите все инклуды в сервисе. И подключайте один сервис
2. ещё раз.... делаете класс который отвечает за структуру. Передаёте ему в конструктор те данные которые он должен валидировать. В конструкторе проверяете эти данные. Если проверка не прошла - исключение. Если прошла - у вас гарантированно нормальная структура. То есть, если модулю приходит объект структуры - он гарантированно содержит валидные данные. Что ещё надо? Не хотите исключение, делайте метод $oStructure->isValid() и проверяете в модулях. Вроде ж очевидно... не?
 

Adelf

Administrator
Команда форума
Их же надо будет потом подключать, следить чтобы файл с классом в нужной папке находился и прочее.
Боязнь "плодить" классы - не есть хорошо. Проблема нужной папки... это уже совсем плохо :)
Погляди нормальные фреймворки. Там проблемы "нужной папки" не стоит. советую взять оттуда хотя бы автолоадеры.
 

korpus

злой бобёр
Adelf, здесь вопрос несколько в ином. Дело в том, что разбивать на модули-классы в данном случае не имеет смысла, так как эти модули никогда не будут использоваться отдельно. Получается, что деление на модули, например, на модуль делающий запрос и на модуль парсящий ответ, только усложнит задачу. В фреймворке такое деление необходимо, так как один и тот же класс может использоваться в целом ряде задач. Мне же надо просто написать класс для решения задачи, хоть эта задача и очень многогранна, и мне пока даже неизвестно, в каком фреймворке и будет ли мой класс использоваться.
Поэтому применение божественного объекта считаю оправданным.
 

korpus

злой бобёр
К тому же если верить википедии он и исполняется быстрее :)
 

Adelf

Administrator
Команда форума
korpus
Смысл разделения на классы не только в том, чтобы они могли использоваться в разных местах.
Правильно логически разбитая на классы задача, легко поддерживается в будущем и легче проектируется.. легче тестируется. Короче, не буду даже спорить - не хочешь не делай. Вон Духовность тебя поддержит. Он тоже не выделяет методы, если метод будет вызываться всего в одном месте.
 

korpus

злой бобёр
Adelf, а я и не спорю. Как по твоему легче будет разработчику, работающему на фреймворке? Получить один готовый класс, содержащий всю сложную логику, чтобы использовать его в качестве модели в MVC так:
PHP:
$myclass=new myclass:
$resutl=$myclass->get_result($parameters);
и забыть о том, что внутри него сложная структура. Или получить несколько файлов с отдельными классами, которые надо разместить в нужных местах, иметь возможность подключить их все (rкак отдельные модели) и тому подобные сложности? Я думаю, первый вариант проще, а логику внутри класса разбить на методы класса.
 

Raziel[SD]

untitled00
korpus написал(а):
И теперь не нужно проводить проверку в каждом модуле, а всё собрать в одну кучу, так как ясно, что весь класс будет иметь дело только с корректными и один раз проверенными данными.
Каждый класс должен проверять только специфичные для него проверки, тогда не будет дублирования.

Adelf, здесь вопрос несколько в ином. Дело в том, что разбивать на модули-классы в данном случае не имеет смысла, так как эти модули никогда не будут использоваться отдельно....
Поэтому применение божественного объекта считаю оправданным.
Со временем подобные божественные объекты превращаются в адские объекты, потому что в них без поллитра не разобраться.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
классов должно быть много, они должны быть маленькие и выполнять что-то отдельное
 
Сверху