Как абстрагировать аргумент конструктора при таком подходе?

Question

[Daria Motorina]

Столкнулась с ситуацией, когда хочется избежать говнокода, но не знаю как.

Есть пакет Laravel JSON API, есть его документация. Есть классы адаптеров, которые связываются с моделями приложения. В конструкторе указываются стратегии пагинации и классы моделей. Из-за того, что классы моделей задаются инстанциированием внутри конструктора, я не могу вынести метод конструктора в абстрактный класс, чтобы пагинация была везде одинаковая. Не могу писать в абстрактном классе такое, потому что ларавеловская Model - тоже абстрактный класс.

public function __construct(CursorStrategy $paging)
 {
        parent::__construct(new Model(), $paging);
 }

Есть ли способ это отрефакторить такое?

Документация : Cursor-Based Pagination

Пример кода из документации, который демонстрирует проблему:

namespace App\JsonApi\Comments;

use App\Comment;
use CloudCreativity\LaravelJsonApi\Pagination\CursorStrategy;
use CloudCreativity\LaravelJsonApi\Eloquent\AbstractAdapter;

class Adapter extends AbstractAdapter
{

    /**
     * @param CursorStrategy $paging
     */
    public function __construct(CursorStrategy $paging)
    {
        parent::__construct(new Post(), $paging);
    }

    // ...
}

Comments

[BoShurik]

Если я правильно понял, то

abstract class AbstractAdapter extends \CloudCreativity\LaravelJsonApi\Eloquent\AbstractAdapter
{
    public function __construct(CursorStrategy $paging)
    {
        parent::__construct($this->getModelInstance(), $paging);
    }

    abstract protected function getModelInstance();

    // ...
}

[Daria Motorina]

BoShurik, да, спасибо большое,получилось!
Продублируйте ответ, я отмечу решением)

Answer 1

[BoShurik]

Если я правильно понял, то

abstract class AbstractAdapter extends \CloudCreativity\LaravelJsonApi\Eloquent\AbstractAdapter
{
    public function __construct(CursorStrategy $paging)
    {
        parent::__construct($this->getModelInstance(), $paging);
    }

    abstract protected function getModelInstance();

    // ...
}

Answer 2

[Максим]

Я, конечно, слабо знаком с Laravel, но наследование мне не очень нравится. Лучше использовать DI. Поэтому, чтобы не наследоваться от классов фреймворка - просто не наследуйтесь от них) Вот так просто) Создайте свои классы и уже к ним подключите Laravel. Тогда и фреймворконезависимость увеличится. А реализацию настраивайте через DI. У адаптеров может быть метод support, который проверяет поддержку адаптера.

Comments

[Daria Motorina]

Это часть бизнес-логики по реализации JSON API, пакет не позволяет такую гибкость

[Максим]

Daria Motorina, ну вы же сами не первый день в программировании. Много знаете. Изменить то что в конструкторе можно только убрать наследование, либо установить сеттером. Убрать наследование лучше. Но можно и придумать какой-то костыль с геттером или сеттером)

[Daria Motorina]

Максим, да, Вы правы, подход с сеттером легко внедрить (поняла на примере решения BoShurik). Конкретно в этом случае затраты на снижение фреймворкозависимости не оправданы экономически

[Максим]

Daria Motorina, ну тогда таким способом) Тут вариантов не много)