Максим Федоров

в подобных ситуация стоит возвращать null или Null-object в зависимости от того как реагирует Ваш код на ситуацию когда ничего не найдено. Бросать исключение в таких ситуациях - не особо уместно, все таки "не найдено" это не исключительная ситуация а вполне себе обычная... возвращать false - тоже как-то не камельфо (если есть false должен быть и true)

постоянно забываю паттерны, и время от времени освежаю их в памяти

да и не стоит забивать голову лишней информацией и запоминать их все и во всех подробностях. Достаточно понимать какие они есть и какие задачи каждый из них решает. А при необходимости уже смотреть более конкретную информацию по ним.
По GoF-паттернам могу посоветовать designpatternsphp.readthedocs.io/ru/latest/Behavio...

так вот вопрос в следующем, можно ли в одном файле хранить 2 класса? Насколько это правильно?

Нет. это не правильно. Ссылки на стандарты описывающие это привел Дмитрий Энтелис

1. Файл database.php - в нем хранится клас и функции для работы с БД.
2. Файл run.php - там хранятся функции для работы с с каждой строкой из БД (можно сказать основной файл)
3. Файл api.php - функции сторонних сервисов, необходим для run.php
4. Файл config.php - ну тут все понятно чисто переменнные для работы
5. Файл index.php - основной который запускает и объединяет все.

Судя по тому что Вы приводите список файлов с функциональной декомпозицией могу предположить что и в самих файлах у Вас не ООП-код (использование классов это еще не означает ООП). Поэтому рекомендую пройти какие-нибудь курсы по ООП либо почитать соответствующие книги.

И еще вопрос обязательно ли использовать ООП или это зависит от каких то факторов(например показывает уромень автора)?

использование ООП не всегда уместно, все зависит от конкретной задачи. но знание ООП практически везде обязательно

Если правильно понимаю у Вас две проблемы:
1. Вы не знаете как считывать данные из параметров дочерних классов и подставлять их в Ваши запросы.
2. Вы не знаете как заполнить данными параметры дочерних классов полученными из SQL-запроса
За подобного рода преобразования должны отвечать дочерние классы, а родительские класс должен только использовать эти преобразования. Соответственно Вам нужно создать два абстрактных метода реализующих для каждого потомка свои механизмы преобразования.

P.S. почитайте про паттерн Active Record, по сути дела Вы пытаетесь его повторить в некой своей интерпретации

что это вообще такое, как гуглить, где читать?

Это обычная функция обратного вызова реализованная через анонимную функцию. Гуглить соответственно по словам "функция обратного вызова", "Анонимная функция". Читать статьи в интернете, книги по основам программирования ...

Будет неплохо, если будут примеры или толковые объяснения

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

Есть подозрения, что это как-то связано с паттернами проектирования.

Еще раз - это основы и они имеют такое же отношения к паттернам как и циклы, условия и т.п. т.е. никакое.

$newDate = date_create_from_format('Y-m-d', $date);
$newDate->modify('+1 YEAR -1 DAY');
echo $newDate->format('d.m.Y');

ох Вы с названиями и ответственностью классов намудрили, давайте по порядку

Есть модель ModelPosts, в которой мы получаем все из базы данных.

Это не модель. Модель - это набор классов реализовывающих бизнес-логику. У Вас же этот класс реализовывает взаимодействие с базой данных - а это как бы вообще не бизнес-логика. По сути дела класс ModelPosts у Вас выступает в качестве репозитория, который только обеспечивает взаимодействие с базой данных. Репозиторий - это уровень доступа к данным.

Есть объект Post, в котором обычно помещаются данные о посте, после их получения из БД (но у себя в голове никак не могу его определить куда-то при добавлении поста, получается этот объект никак не участвует в добавлении)

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

Добавление поста - это что? в общем случае это просто выполнение определенного запроса к базе данных. А что отвечает за взаимодействие с базой данных? Уровень доступа к данным, в нашем случае это класс ModelPosts (вообще-то не удачное название). Соответственно в нем и должна быть реализация добавления поста в базу данных.

Что касается валидации - реализация механизма валидации должна содержаться в отдельном классе (или классах). Сама валидация может происходить либо в контроллере, либо в модели

1. пройтись циклом по массивам
2. сформировать INSERT-запрос c помощью итераций цикла
3. выполнить запрос с помощью инструмента, через который Вы работаете с базой данных

используйте встроенный в MySQL механизм событий

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

class OrderEntity
{
    /**
     * @var integer Идентификатор заказа
     */
    protected $id;
    
    /**
     * @var MemberEntity Объект покупателя
     */
    protected $member;
    
    /**
     * @var ItemEntity Массив позиций заказа
    protected $items = [];
}

2. Получение данных из базы данных в объект должно быть реализовано в каком-нибудь репозитории или в каком-нибудь датамаппере. Почитайте про эти паттерны. Но вообще лучше взять какую-нибудь вменяемую ORM что бы избежать кучи гемора.
3. По названиям классам - не добавляйте в них суфикс Entity, код становиться из-за этого более нагроможденным, лучше используйте пространства имен

Правильно так как принято в стандарте который Вы используете. Если Вы используете PSR - правильно без пробела, если Вы используете какой-то внутренний стандарт компании в котором обязателен пробел - значит нужно его ставить.

Итог: Нужно просто соблюдать правила используемого Вами стандарта