Нормален ли такой подход в организации моделей данных?

Question

[Антон Шилов]

Допустим ли такой подход в организации классов моделей данных (см. пример кода) или же это неверный путь? Мне удобнее когда классы сопутствующие основной модели данных располагаются в том же файле и доступ к ним обеспечивается именно через основной класс, но приемлем ли такой вариант использования или же категорически нет, и какие это может вызвать проблемы?

Модель User, файл User.php

class User extends ActiveRecord
{
    public static function getUserLinksObj()
    {
        return new UserLinks();
    }
}

class UserLinks extends ActiveRecord
{
    public static function findLinks($userId)
    {
        return static::find()->where(['user_id' => $userId])->all();
    }
}

Использование

$userLinks = User::getUserLinksObj()->findLinks($userId);
// дальнейшая обработка

Хотелось бы услышать ваше мнение по этому вопросу.

Answer 1

[Алексей Уколов]

По большому счету, у вас два вопроса:
Можно ли хранить несколько классов в одном файле?

Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4].
This means each class is in a file by itself, and is in a namespace of at least one level: a top-level vendor name.

PSR-1
Проблемы такой подход может вызвать только если вы начнете работать в команде, в которой принят какой-то другой стандарт. При наличии современных IDE нет никакой разницы в каком файле лежит класс и поэтому нет никаких причин не писать каждый класс в отдельный файл - так их будет проще читать и искать.

Можно ли вызывать один класс через другой

$userLinks = User::getUserLinksObj()->findLinks($userId);

Если уж вы инкапсулируете, так инкапсулируйте так, чтобы было удобно пользоваться:
$userLinks = User::findLinks($userId);

Но в таком случае почему бы не написать сразу нормально?
$userLinks = UserLinks::findForUser($userId);
Зачем такая сильная связь между классами? У каждого класса - своя зона ответственности.

Answer 2

[dmitriy]

мне кажется здесь автору необходимо знать, верен ли подход получения данных через другой класс,
а как хранить класс в этом файле или в другом дело вкуса.
Aggregate Root .
Если UserLinks объект не может существовать без объекта User, то User выступает в роли родительского элемента в узле через которого происходит получение дочерних элементов.