- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
$id_country = 0;
$id_region = 0;
$id_city = 0;
$zip_code = 0;
if(isset($_REQUEST["id_country"]))
{
$id_country=$_REQUEST["id_country"];
}
if(isset($_REQUEST["id_region"]))
{
$id_region=$_REQUEST["id_region"];
}
if(isset($_REQUEST["id_city"]))
{
$id_city=$_REQUEST["id_city"];
}
if(isset($_REQUEST["zip_code"]))//проверка zip кода
{
$zip_code=$_REQUEST["zip_code"];
}
$id_country=strip_tags(trim(strval($_REQUEST["id_country"])));
$id_region=strip_tags(trim(strval($_REQUEST["id_region"])));
$id_city=strip_tags(trim(strval($_REQUEST["id_city"])));
$zip_code=strip_tags(trim(strval($_REQUEST["zip_code"])));
..........................
//переходим на Шаг 2 решистрации
header("location: ./registration.php?sel=2");
..........................
Follow us!
Сначала нагородить огород, а потом вовсе его не использовать. Его можно в учебники вносить. :)
А количество полей большое всегда плохо. Априори каждое поле уникально и требует индивидуального подхода. Правда код в данной интерпретации мог быть и укорочен каким-нибудь циклом. Однако, я склонен полагать, что здесь вновь действует один из приёмов "парадигмы быстрого программирования" - создать кусок кода "на потом", авось пригодится, авось для каждого поля придётся применять свою стратегию.
Тут в чём вопрос. Предположим нужно обработать поле "номер телефона". Я предполагаю "правильные" номера: xxxxxxx, xxx xx xx, xxx-xx-xx, где x - цифра. Но внутри храню всегда xxxxxxx, где x - цифра. Тот факт, что номер должен из формы в переменную попасть одним из трёх видов - это условие правильной работы скрипта, он не сможет понять номер, если он будет xx-x-x-x-xx, а x - буква. Это предусловие. Соответственно, класс-менеджер должен иметь для этого случая метод (функцию-член) ValidatePhoneNumber($phoneNumber) - этот метод есть контракт входящего типа. Я принимаю только номера определённого типа и для проверки вызывают определённый метод, которым должен обладать класс-менеджер. Но кроме того я храню номер в виде числа. И будет существовать метод, который принимает уже не произвольную строку, а определённого вида и сохраняет её числом SavePhoneNumber($validPhoneNumber) - это моё дело (а вот номера, скорее всего, в одном и том же формате все будут принимать, и я, и вы), как работает эта функция-член. Но она тоже должна быть, я её использую, она входит в контракт.
Поля, скорее всего, часто будут иметь что-то очень схожее и я смогу написать несколько стратегий: стратегии сохранения, стратегии проверки. После чего проверю какие у меня встречаются поля в данной форме и сформирую класс, реализующий определённые стратегии, из них состоит полный набор методов класса, эти методы будут разбиты на пары, для каждого поля (или нескольких похожих), эти пары и есть контракты с полями.
Ну как-то так...
Вообще говоря я имел ввиду что-то подобное. О глубине реализации можно рассуждать в зависимости от проекта. Я бы для валидации/сохранения различных типов полей использовал различные стратигии, наследуемые от базовой, реализующие некий интерфейс и т.п.
p.s.>говнокод потихоньку превращается в общение на тему "а как бы сделал я"
Я тут newbie. Не знаю ещё, что принято.
Я свою первую реплику ("Индус" - это уже собирательный образ) написал к тому, что количество полей в любом случае нас заставит потратить человеко*часы. При подходе без ООП можно будет нашарашить функций-нечленов. Суть не изменится. Другое дело, что если остановиться и задуматься...
>>различные стратигии, наследуемые от базовой, реализующие некий интерфейс
...то возникнет вариант, который можно использовать удобно В РАЗНЫХ проектах. Да, на одном сайте не выиграем, зато насколько быстро сможем создавать новые классы для обработки форм в будущем. Соединим различные стратегии в одном контракте и получим новый класс-обработчик. Для другого сайта другой. Но при этом быстро и интерфейс будет равен контракту, а ничего нового мы и не писали, просто комбинировали написанное.
Отыскивать куски для копирования на новый сайт из кода вида данного #1679 "говнокода" будет в разы сложнее. Тогда и будет удобнее написать сайт заново. И тут вопрос скорости кодирования "индуса". Он может настолько быстро кодировать, что даже заново будет быстрее, чем у других с повторным использованием. Потому нужно и продуманное решение и быстрое. Именно это и порождает "индусов".
Если есть хорошая команда, которая может создать хорошее ПО, зачем заставлять её кодить? Пусть они напишут хороший core, а на него мы будем навешивать что-то быстро. Пригласим тех, кто пишет код быстро, не важно как... Потом будут заплатки... Это позволяет быстрее выйти на рынок. Скорость разработки для интернета ещё требовательнее, потому "плохого" кода на популярном языке будет много, потому что нужна скорость выхода на рынок.
Там очень много методов, они составляют полный интерфейс класса. Но, положим, я или вы используем только десять из них. Эти десять методов - наш контракт с классом mysqli. Он мог бы ничего не делать, кроме этих десяти методов, а сценарий работал бы. Но если он не реализует в интерфейсе хотя бы один метод из контракта, то сценарий не работает, даже есть mysqli будет ещё тысячу методов иметь.
Соответственно, если вы используете класс с большим интерфейсом при небольшом контракте - вы используете класс неэффективно.
С другой стороны вы могли бы, скажем, брать данные из базы и записывать в файлы. Вам нужен контракт из методов и того, и другого. Тогда вы можете создать новый класс, который соберёт часть методов из класса ресурса баз данных и часть методов из класса работы с файлами. Получится новый класс, который делает то, что нужно.
ЗЫ: отсыпьте )
мну плачет...
$id_city=strip_tags(trim(strval($_REQUES T["id_city"])));
выглядит короче чем
$id_city = (int)$_REQUEST['id_city'];
8))