ООП реализация сомнений

Во-первых, вы поступаете правильно, бросая вызов себе.

Очевидно, что есть много способов делать вещи.

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

Это было бы одним из способов сделать это:

Для обработки моделей и конструкций

Entity/User (Define the properties of a user)
Collection/User (implements ArrayIterator, just a structure)

Для связи с вашим репозиторием (db).

Repository/Mysql/User (implements getAllUsers, saveUser, deleteUser, etc.)

Эти классы должны реализовывать общие интерфейсы или наследовать общие абстрактные классы (если они имеют общую логику).

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

У меня есть структура Data Model, похожая на вашу, где классы представляют свои таблицы. В случае получения множественного числа "Пользователь" или "Категории" и т.д. У меня есть статический метод внутри класса, который возвращает экземпляры класса. В примере:

class User{
    public static function fetchUsersForBusiness(Business $business){
        //fetch code here into variable $users from database...
        $userObjs = [];
        foreach($users as $userData){
            $userObjs[] = new User($userData);
        }
        return $userObjs;
    }
}

class Business{

}

Следующий код вернет всех пользователей, которые соответствуют определенным критериям (в данном случае бизнес, с которым они связаны). Затем я возвращаю их как сами объекты.

Я нашел эту модель довольно успешной и использовал ее на множестве языков, включая Java, PHP и Swift. Надеюсь, это поможет вам.