Комментарии к статье «Strategy Pattern в PHP»

	Cainrus
Вы не правы насчёт того что можно обойтись с помощью одной функции, которая будет проверять поля с соответствием их с установленными проверочными переменными( регулярные выражения, длинна поля и т.д. ). А что если однажды добавится новое скрытое системное поле, которое нельзя выбирать самому? например, номер текущей сессии, которая может храниться где угодно, хоть в БД. По Вашему примеру придется, либо дополнять функцию дополнительными переменными( как максимальное/минимальное кол-во символов в строке, паттерны регулярных выражений ), а затем прописать логику в функции, что будет выглядеть не красиво и путать программиста, увеличивая возможность багов, усложнять читаемость. Приведённый автором статьи пример класса валидатора легко расширяем и каждый новый наследуемый валидатор содержит свою логику только на свой частный случай, что не делает из кода каши, ускоряет разработку/исправления/дополнение кода в будущем, повышает читаемость снижает вероятность появления багов.

	fadanys
>>формат вывода ошибок может различаться от одной страницы к другой ........ >Это как? Зачем? например в разных разделах сайта. В статьях этого сайта речь идет вообще о шаблонах проектирования. То есть подразумевает возможность использования решения в различных проектах. >> но ООП представляется более удобным, так как не требует создавать переменные в вызывающем скрипте ........... > А что по Вашему значит $v['a'] = new ValidateNNN(); ? я имею ввиду какие либо дополнительные стрктуры для хранения сообщений и результатов. >>А какое собственно назначение у классов? ............ >Предоставлять пользователю инструмент для построения собственных типов, отражающих конкретные понятия, которые НЕЛЬЗЯ прямо и естественно отразить при помощи встроенных типов. Использование новых типов должно быть таким же удобным и прозрачным, как использование встроенных типов, что достижимо при работе через интерфейсы. Хм.. а я всегда считал, что для использования инкапсуляции, наследования и полиморфизма. инкапсуляция подразумевает проверку данных, а наследование – возможность описания в базовом классе неизменяемых функций и соответственно неповторяемость кода, полиморфизм – использование одинаковых вызовов.

	!true
>по хорошему нужно выводить все сообщения о неправильном вводе, а не только последнее. то есть хранить в массиве или отдельных переменных. .............. Посмотрите на описание функции-члена повнимательнее: `<?php public static function validateText(&$text, &$errstr, $sizeMin = 1, $sizeMax = 65536, $regexp = NULL) ... MYNAMESPACE::validateText( $_POST['user'], $errmsg, 6, 20 ); ?>` Если что, то передача $errmsg по ссылке подразумевает в определения функции-члена конкатенацию $errstr .= '...' (то есть $errmsg .= '.....') Никаких других переменных там не нужно. >формат вывода ошибок может различаться от одной страницы к другой ........ Это как? Зачем? > но ООП представляется более удобным, так как не требует создавать переменные в вызывающем скрипте ........... А что по Вашему значит $v['a'] = new ValidateNNN(); ? >возможно изменение внутреннего формата, внесением изменений только в один класс. ........... Но не в этом примере. >А какое собственно назначение у классов? ............ Предоставлять пользователю инструмент для построения собственных типов, отражающих конкретные понятия, которые НЕЛЬЗЯ прямо и естественно отразить при помощи встроенных типов. Использование новых типов должно быть таким же удобным и прозрачным, как использование встроенных типов, что достижимо при работе через интерфейсы. Почему в примере не нужны классы? Потому, что абсолютно любое поле html-формы можно прямо представить при помощи уже встроенных в php типов. Потому, что в php уже присутствуют операции приведения базовых типов. И потому, что в php уже реализованы механизмы валидации этих типов.

	fadanys
2!true структурное программирование — это уже лучше. но именно по этому коду: по хорошему нужно выводить все сообщения о неправильном вводе, а не только последнее. то есть хранить в массиве или отдельных переменных. Учитывать, что формат вывода ошибок может различаться от одной страницы к другой. все это можно сделать и используя функции (я вовсе не против такого подхода), но ООП представляется более удобным, так как не требует создавать переменные в вызывающем скрипте, возможно изменение внутреннего формата, внесением изменений только в один класс. > Для классов есть вполне конкретное назначение. А какое собственно назначение у классов?

	!true
(возможно, нужно пофиксить) В строке с валидацией пароля скрипт урезал бэкслэш перед знаком доллара в регулярном выражении. test (one slash): *test (escaped slash): \

В итоге выглядит так:	!true
<?php // ================= // <submit_user> //================== if ( isset($_POST['register']) ) { $errmsg = ''; /* if ( !MYNAMESPACE::validateText(...) ) { some action } or MYNAMESPACE::validateText(...); */ MYNAMESPACE::validateText( $_POST['user']), $errmsg, 6, 20 ); MYNAMESPACE::validateText( $_POST['password']), $errmsg, 6, 20, '/^[a-zA-Z0-9_]+$' ); MYNAMESPACE::validateText( $_POST['email'], $errmsg, 6, 100, ); if ( !MYNAMESPACE::validateType( $_POST['int_favourite'] ) $errmsg .= '...'; if ( $errmsg !== '') echo $errmsg; else { ... } } // ================= // </submit_user> //================== ?> Зачем придумывать что-либо еще?

	!true
fadanys Мое предыдущее сообщение сводилось к мысли, что метод, описанный автором, мало чем отличается от решения в лоб. И отнюдь не в лучшую сторону. >но если форм несколько, в разных местах и есть поля с одинаковой функциональностью, то идея Наследования ООП выглядит очень симпатично ........... Как это меняет дело и так уж ли это симпатично? Представим, что у нас есть веб-интерфейс для работы с БД, в которой содержатся несколько таблиц. Для каждой таблицы – отдельная форма (всего M). В каждой форме по 20 полей. Предположим, что M (M <<< N ) из них и вправду идентичны по заполняемым структурам. Так что, нам действительно импонирует определять N-M наследников с теми же if () конструкциями? Для классов есть вполне конкретное назначение. Данная статья – пример того, как не нужно использовать классы. С подобными задачами отлично справляются функции. При желании – разрешенны относительно определенного пространства имен. `<?php class MYNAMESPACE<br>{<br> public static function validateText(&$text, &$errstr, $sizeMin = 1, $sizeMax = 65536, $regexp = NULL) { ... return true; } public static function validateType(&$value, $type = 'int') { ... return true; } } ... // ================= // <submit_user> //================== ... ?>`

true	fadanys
для одной формы конечно можно проверять влоб, но если форм несколько, в разных местах и есть поля с одинаковой функциональностью, то идея Наследования ООП выглядит очень симпатично. Можно конечно сделать на простых функциях, но тогда все переменные все равно нужно объявлять отдельно в обработчике каждой формы.

классомания?	!true
В чем смысл городить кучу классов, в методах которых присутствуют те же самые if(), а после для каждого(!) проверочного поля создавать отдельный объект? Не говоря уже о циклах. `<?php // ================= // <submit_user> //================== if ( isset($_POST['register']) ) { $errmsg = ''; ... if (...) $errmsg .= '...'; if (...) $errmsg .= '...'; if ( $errmsg !== '') echo $errmsg; else { ... } } // ================= // </submit_user> //================== ?>` И все. Если программист в таком блоке кода способен создать баг или не найти определенную строку, то ему, вообще говоря, стоит либо пойти учиться, либо сменить профессию.

developer.co.ua

Комментарии к статье «Strategy Pattern в PHP»