Sinus_314

Если строго следовать принципам SOLID, а именно SRP (принцип единственной ответственности), то задачей контроллера является презентовать какую-то часть приложения в виде HTTP endpoint (в частном случае REST).

Собственно логика не должна находиться в контроллере, потому что способы обращения к этой логике (через HTTP, Service Bus, Telegram, Discord, периодический вызов по крону и т.д.) ортогональны собственно бизнес-логике.

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

В чем проблема написать в контроллере пару where, join, мб как-то по хитрому обработать данные?

Завтра появится задача сделать всё то же самое, но в консоли. Потащищ копипасту или начнёшь выносить общий код в реквесты, репозитории и прочие места?

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

Репозитории актуальны с паттерном DM и не актуальны с паттерном AR.

При всём при этом следует помнить, что паттерны — не догмы. Паттеры для человека, а не человек для паттернов. Если у тебя одностраничник на хайповую тему, который надо сделать быстро и жить ему месяца два, то не парься и пиши всё в контроллерах. Выживет — перепишешь.

Передать-то можно:

$data = $api->getJson();
$model = new YourModel($data);

Но только проще создать свои модели, не связанные с Eloquent (можно в них добавить трейт HasAttributes, если нравится его поведение), а не пытаться натянуть ужа на ежа. В "стандартной" модели очень много всего завязанного на Eloquent и подменить его будет сложно, лучше потихоньку добавлять нужную функциональность руками.

Ну а контроллерам вообще всё равно с какими объектами работать.

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде ( сортировка, текущая страница в блоге, строка поиска и т.п. ).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта ( логины, пароли, номера кредиток, сообщения и т.п. ).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

С какой осью?

Если с windows, то есть пакет Win32 - низкоуровневый, но зато всё в одной куче.

Если с линуксами, то можно читать файлы из /proc.

Для захвата экрана можно взять что-нибудь кроссплатформенное вроде gtk. Но если хочется прям стримить экран, я бы уже не стал выпендриваться и поискал способ сесть поверх ffmpeg.

Переформатировал код под себя. Не могу воспринимать египетские скобки.

void Printer::addM(Moved obj) 
{
  Moved* tmp = new Moved[mSize];
  for (int i = 0; i < mSize; i++) 
  {
      tmp[i] = objs[i];
  }
  objs = new Moved[++mSize];
  for (int i = 0; i < mSize - 1; i++)
  {
    objs[i] = tmp[i];
  }
  objs[mSize - 1] = obj; 
  Car mytmp; // для теста
  cout << mytmp.getType() << endl; // для теста
  cout << objs[mSize-1].getType() << endl; 
  Sleep(100);
}

У вас две проблемы. Во-первых вы зачем-то переизобрели std::vector, поэтому вам приходится писать примерно в 5 раз больше кода чем надо.

Во-вторых, вам надо хранить не объекты Moved, а указатели на них, и тогда ваша гомологическая иерархия классов заработает.

Как я и говорил выше, addM работает не так, как вы ожидаете. Когда вы ее вызываете, у вас происходит создание Moved на основе Car или Walker, что исключает полиморфизм.

for (it = catalog.begin(); it != catalog.end(); ++it)
{
        it->click();
}

передать в функцию указатель на list

Вы полностью указали тип?
void foo(list<File>* pList);