понеслась)


Первое, ТС не просил всех возможных вариантов. Он задал конкретный и недвузначный вопрос. Про валидацию там не было ни слова. Если разбирать все возможные варианты, можно написать целый фреймворк.


Как твой фреймворк? = )

да про валидацию не было ни слова но дальше Т прилагает следующий код

//Вот вариант в массивом
if(!empty($_POST['date'])){
  $obj->filter(array('date' => $_POST['date']));
}
$obj->getAll();

//И с отдельным методом
if(!empty($_POST['date'])){
  $obj->filterDate($_POST['date']);
}
$obj->getAll();

а вот слово filter уже указывает на валидацию, так что ТС всегда пожалуйста, а тебе Твин стоит повнимательнее читать топик.


Ну и по порядку:
Цитата (Guest @ 26.01.2019 - 20:12)
1) как применяются данные, куда они дальше идут?
Это совершенно не важно на данном этапе. Важно в каком виде их представить.

Конечно это не важно, какая разница.


) если части данных нет, как исключения или как ошибка ,что будет происходить?
Это тоже не важно, так как валидация - другая ответственность. В транспортный объект должны поступать уже валидные данные. Так как он отвечает только за транспортировку (SOLID)

конечно это все неважно



расширение поступающих переменных в функции планируется? Вижу по задаче что да, и ? что дальше?
Может и планируется, но. В разных местах может быть разные расширения -


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


Так что весь твой дальнейший код - явное и грубейшее нарушение YAGNI, что есть суть bad practices.

Весь мой код это пример упрощениятго что писал серж и brevis и каким им распорядится ТС его дело , и писал я его ориентируясь на правило

Keep it simple, stupid

Не плодите сущностей сверх своих потребностей

а они лежат в основе всех остальных правил


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


с толку меня сбил ты, мы совсем отошли от темы с валидацией, поэтапным выводом и прочей чушью

мое предложение состояло в том что бы за место тучи классов и дублей кода использовать

property_exists($this, $key) ;
funct = 'validate'.$key;
$this->$funct($val) ;


я и подумать не могу что если добавить валидацию это станет такой проблемой



Так что brevis представил вполне исчерпывающий ответ. Вот его можно было бы разобрать, потому что он довольно спорный, но не по сути, а в плане реализации. ито только потому, что реализация не представлена и может трактоваться по разному.

то это нужно делать в обратную сторону. Посредством интерфейса ArrayAccess


код в студию, давай = )

И атк что дает мое решение
1) сокращение дублирующего кода
2) ускорение работы
3) простоту адаптации

что дают твои терзания

SOLID с упором на буквы O и S
транспортный объект
кучу классов
YAGNI

твин, я признаю что использую просроченный var , да мне атк проще я приык , даже не обращал на это внимание, но и ты просто признай что не разобравшись стал обливать код грязью

сейчас что-то будет ))))

property_exists($this, $key) ;
funct = 'validate'.$key;	
$this->$funct($val) ;

twin

но и ты просто признай что не разобравшись стал обливать код грязью
Разобравшись. Ну что обливал - признаю.

т.е. ты так извиняешься?



Это сюр какой то. Совершенно нечитабельный и антипаттерный.

не циклись на ООП команда 4 ех или как их там и все остальные разрабы, описывающие принципы разработки и паттерны указывали -ребят не сходите с ума на шаблонах.


и да это сюр

Сюрреализм — направление в литературе и искусстве двадцатого века, сложившееся в 1920-х годах. Отличается использованием аллюзий и парадоксальных сочетаний форм.

Но именно нестандартное мышление приводит к новому, поиски новых решений, поиск нового мышления.

5 строк кода заменяют библиотеку функций, может это и СЮР но он эффективен


Твин, рано или поздно придется начать мыслить без учебников, почему бы не начать сегодня?

хорошо давай сравним
каждый напишет свое решение

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

Вся твоя бяда в том, что ты неверно интерпретируешь понятия.

Тот же KISS совсем не призывает к уменьшению объема кода. В твоем случае как раз наоборот. Ты усложняешь реализацию, вместо того, чтобы сделать просто. Не нужно никакой магии, она вредит. Вот это вредный код:

funct = 'validate'.$key;	
$this->$funct($val) ;

Смотри. Допустим есть свойство $date. Дата, как ты понял. Соответственно при инициализации свойства будет задействован метод validateDate(). Не станешь же спроить?)))

Так вот. В одном конце системы потребуется дата в азиатском формате, в другом в европейском, а в третьем вообще timestamp. И что делать? Валидация свойства у тебя захардкожена в классе транспортного объекта, да еще и жестко привязана к имени свойства. Что ты станешь делать?

Можешь не отвечать, все что ты предложишь, это костыль.

Так что ты попытался упростить код, на самом деле усложнил его дальнейшее обслуживание. А KISS как раз и гласит - не мудри. Делай просто. Нужна валидация, делай валидацию. Конкретную, к месту пригодную. Это очень прозрачно и всем понятно. Просто.

Ну и остального тоже касается. Ты видишь верхушки, а сути не понимаешь. Так что возвращаю тебе это:

twin

вооот наконец то добрались до настоящей работы и рассуждений, поехали

Смотри. Допустим есть свойство $date. Дата, как ты понял. Соответственно при инициализации свойства будет задействован метод validateDate(). Не станешь же спроить?)))

Так вот. В одном конце системы потребуется дата в азиатском формате, в другом в европейском, а в третьем вообще timestamp. И что делать? Валидация свойства у тебя захардкожена в классе транспортного объекта, да еще и жестко привязана к имени свойства. Что ты станешь делать?

Можешь не отвечать, все что ты предложишь, это костыль.



Т.е. давай уточним, мы абстрогируемся от ТС и подходим к продумыванию некого класса каталога содержащего к примеру товары
и для данных товаров нужен класс который имеет интерфейсы ввода информации и ее вывода верно?

Да согласен но и ты признай что это совсем иная реализация.

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

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

Приложение со множеством потоков общающихся друг с другом, за каждую микросекунду за каждый байт идет война. Хоть на стене напиши это рабоатет на паттернах - оно дольше, тяжелее ? -списано

И кстати не факт что новый программист который придет, на твое место должен знать паттерны, а вот программу он должен быстро изменять, открываешь код и видишь оболочка внутри оболочки внутри оболочки внутри оболочки

так что спасибо себе оставь

Ну и остального тоже касается. Ты видишь верхушки, а сути не понимаешь. Так что возвращаю тебе это:

на говнокод.ру
любого можно послать

а извиняться нужно за то что неразобравись в предназначении участков кода бросился с обвинениями

Пиши, я его исправлю по своему разумению. Мне лениво, ибо это ничего нового мне не даст.
угу, слил бой

Паттерны, антипаттерны, решения, первичен объект ане его реализация

Яркий пример singleton сначала был паттерном потом стал антипаттерн , все чушь юзали юзают и будут юзать