_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

понятно

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

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

Наркотики? Да в них есть какая-то фишка

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

Это нормально?

Я бы сформировал объект request и session. Их ненадо объединять, сущности совершенно разные. Инициализировать вместе с ядром при наличии в них данных. Дальше дергать из утилитного (статического) класса в любом месте системы.

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

Получим "транспортный" объект с данными, вместо массива. В нем можно производить дополнительную обработку через геттеры и сеттеры. Может натравливать сам на себя валидатор и определять свое состояние в любой момент времени. Удобно пускать такую штуку в путешествие через бизнес-логику.

Я хочу изначально научиться писать правильный и максимально безопасный код (насколько смогу))) Это я еще учусь) а учиться надо правильно)

Arh
Инъкции? Хм. Интересный термин для суперглобальных. надо погуглить

Ron

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

Обычный термин для внедрения зависимостей.

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

$old = $_GET['key'];
$_GET['key'] = 'нужное значение';
$Obj = new Controller(); 
$Obj->result();
$_GET['key'] = $old;

//vs

$Obj = new Controller([
    'key' => 'нужное значение'
]); 
$Obj->result();

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

$request = new Request($_POST, ['key' => 'нужное значение']);
$controller = new Controller($request->get);

$_GET['key'] = 'нужное значение';
$Obj = new Controller(); 

$Obj = new Controller(['key' => 'нужное значение']); 

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

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

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

Какая у меня репутация?

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

Я понимаю к чему ты клонишь, но ты слишком загоняешься в рамки ООП.
Допустим есть общий класс, для работы с комментариями. Он зависит от значения адресной строки, так он определяет какие комментарии показать на текущей странице.

$Comment = new Comment($_REGUEST['uri']);

Если бы он в контроллере получал адрес, то зависел бы от $_REGUEST и было бы проблематично вызвать этот класс внутри приложения на другой странице. Типа /news/id/1 это страница новости, а еще можно запросить комментарии аяксом прямо в списке новостей /news/last, /news/top.
Так вот $_REGUEST['uri'] это зависимость, это не массив и не объект, это вообще строка.
То есть класс зависит от данных, неважно какой у них тип, в данном случает от данных типа string.
Да и вообще классы тут не причём, обычная функция зависит от параметров переданных в неё.
Инъекция это введение, внедрение.
По этому: "тут фишка не в защите супер глобальных массивов, а в их инъекциях."

Эгоцентричная

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

та не, у него репутация, что он постоянно что-то спорит с twin'ом. И по-делу и не по-делу.

Кстати, я то же использую "внедрение зависимостей" вот такое:

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