Сергей delphinpro

Надо выставить в XShell кодировку UTF8.

Ничего не будет. Подключайте хоть на 100 А.
Мощность, написанная на зарядном - это его максимальная мощность, по сути пропускная способность.
Планшет при подключении "возьмет" ровно столько, сколько ему нужно (то есть 2 А).

Для популярных фреймворков обычно есть демо приложение, нп. Symfony demo app. У Laravel был курс "как был создан Laracasts", т.е. есть живой проект Laracasts и скринкаст по его созданию в целях обучения. В целом на гитхабе есть море готовых приложений разного качества и сложности, главное погуглить основательно)

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

Добрый день!

Когда Вы задаётесь вопросом поддержки и совместимости, той или иной технологии, смело идите на х ороший такой ресурс "CanIUse", в поисковой строке которого, пишите интересующее Вас. В результате вам отрендерится таблица поддержки запрашиваемого по всем браузерам.

caniuse.com

в цикле
все операции над массивами производятся в цикле
для перебора массивов в РНР используется оператор foreach

https://www.ozon.ru/context/detail/id/137538198/

https://ruogp.me/

Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

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

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

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

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.

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

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

index.php

<?php
# Author - Fedor Vlasenko, vlasenkofedor@gmail.com
define('METHOD', $_SERVER['REQUEST_METHOD']);
define('URI', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH));

function router($url, ...$args)
{
    (empty($args[1]) || false !== strpos(METHOD, $args[0]))
    && (URI === $url || preg_match('#^' . $url . '$#iu', URI, $match))
    && die(call_user_func_array(end($args), $match ?? []));
}

router('/api/games', 'GET', function () {
    echo 'список игрушек';
});

router('/api/game/(\d+)', 'GET', function (...$args) {
    echo 'информация о игрушке: ', $args[1];
});

router('/api/games', 'POST', function () {
    echo 'добавить новую игрушку';
});

router('/api/games/(\d+)', 'PUT', function (...$args) {
    echo 'обновить существующую игрушку: ', $args[1];
});

router('/api/games/(\d+)', 'DELETE', function (...$args) {
    echo ' удалить игрушку: ', $args[1];
});

header($_SERVER['SERVER_PROTOCOL'] . ' 404 Not Found');
echo '404';

далее в консоли запускаем встроенный php сервер
php -S localhost:8000 index.php
тестируем и наслаждаемся :-)