Как гарантировать наличие метода в наследнике без привязки к аргументам?

Question

[Александр Силаев]

Есть базовый класс MyBase. Моя цель гарантировать, что в каждом наследнике будет объявлен метод myMethod, но мне нужна свобода в объявлении аргументов.
Т.е. мне нужно примерно следующее

abstract class MyBase
{
    abstract public function myMethod();
}

class Foo extends MyBase
{

    public function myMethod(string $s)
    {
        //
    }
}

Но, по понятным причинам, в таком виде я сделать этого не могу.
Проблему могу решить, убрав вообще абстрактный метод myMethod в классе MyBase. Но таким образом я лишь обхожу проблему, а не решаю ее.
Можно ли сделать это "правильно"? Или вообще такой подход некорректен и по-хорошему надо делать как-то иначе?

Конкретный пример: класс для некой задачи (например достать данные из бд, преобразовать некоторые данные и т.д.), у который есть метод run; базовый класс реализует внутренние процессы (например логгирование в бд, вывод инфы в консоль, запуск хуков и т.д.) и запуск метода run; каждая конкретная задача может принимать аргументы для своего исполнения => аргументы хочется принимать именно в методе run с проверкой типов.

Comments

[Дмитрий]

Можно сделать отдельный метод setArgs(array $args): void
Либо использовать функции для работы с аргументами или сделать аргументы переменной длины

[Кирилл Несмеянов]

abstract class MyBase
{
    abstract public function myMethod(...$args);
}

Это максимум что возможно.

[FanatPHP]

Кирилл Несмеянов, но не нужно. Это именно что костыль, чтоы обойти ограничение которое не позволяет выстралить себе в ногу

Answer 1

[Daria Motorina]

Перегрузки методов в php нет. Лучше продумать правильно архитектуру, чтобы набор аргументов был стабильным на уровне абстрактного класса/интерфейса, чем передавать методу переменное количество аргументов и искать потом причины багов и повод для рефакторинга. Также переменное количество аргументов дает соблазн давать методу лишние полномочия, размазывая его первоначальное предназначение.
На уровне конструктора класса можно через dependency injection передать классы для логгирования, вывода инфы в консоль, тогда в методе run их не нужно передавать, но можно использовать внутри метода.

Comments

[Александр Силаев]

Спасибо за ответ. Речи о переменном кол. аргументов и не идет, не хочется терять нативную возможность проверки типов аргументов.
Классы для логгирования, вывода инфы и т.д. именно в конструкторе (по заветам di) и передаются. Я же имею ввиду аргументы, которые могут понадобится конкретной задаче, например: задача выбора данных из бд с некой обработкой; аргументы - название таблицы и функция обработчик (уточню, пример надуманный).
С радостью бы хотел изменить архитектуру, но не приходит в голову как грамотно оформить такой функционал иначе

abstract class MyBase
{
    protected $dependencies = [];

    public function __construct(ConsoleOutput $consoleOutput, Logger $logger)
    {
        $this->logger        = $logger;
        $this->consoleOutput = $consoleOutput;
    }

    public function runMyMethod(array $params = [])
    {
        $this->consoleOutput->print('start at ' . microtime(true));

        $result = $this->myMethod(...$params);

        $this->consoleOutput->print('end at ' . microtime(true));

        return $result;
    }

    public function __call(string $name, array $arguments)
    {
        $class = $this->dependencies[$name];

        /**
         * @var MyBase $base
         */
        $base = new $class($this->consoleOutput, $this->logger);

        return $base->runMyMethod($arguments);
    }

    // abstract protected function myMethod();
}

class Foo extends MyBase
{
    protected $dependencies = [
        'bar' => Bar::class,
    ];

    protected function myMethod()
    {
        $this->logger->log('Foo myMethod');

        return $this->bar('str', 5);
    }
}

class Bar extends MyBase
{
    protected function myMethod(string $s, int $i)
    {
        $this->logger->log('Bar myMethod');

        return $s . ', ' . $i;
    }
}

[Евгений Ромашкан]

Александр Силаев, Вы нарушаете Liskov Substitution Principle(LSP), не нужно так делать в принципе.
Если метод наследника требует обязательные дополнительные аргументы, значит него нельзя поставлять вместо родителя.

Пусть это будут разные контакты и всё.

[Александр Силаев]

Евгений Ромашкан, я понимаю, что это вряд ли хороший подход, но интересно как сделать более грамотно.

Пусть это будут разные контакты и всё.

можете пожалуйста чуть подробнее пояснить, что под этим подразумевается?

[Евгений Ромашкан]

Александр Силаев,

можете пожалуйста чуть подробнее пояснить, что под этим подразумевается?

Если у вас в родительском классе есть метод bar() без аргументов, а в дочернем нужен bar(string $someArg), то есть с аргументами, избавьтесь от наследования, и пусть это будет два разных класса с разными интерфейсами.

Из вашего описания очевидно что перед ними совершенно разные задачи стоят.

[Александр Силаев]

Евгений Ромашкан, а каким образом это меня избавит от копипасты кода? То, что в моем примере в базовом классе, надо будет описывать в каждом отдельном классе без общего родителя.
Перед классами стоят разные задачи, верно, но "сервисный функционал" (логи, вывод, etc.) у этих задач будет идентичный.

[Евгений Ромашкан]

Александр Силаев,

Перед классами стоят разные задачи, верно, но "сервисный функционал" (логи, вывод, etc.) у этих задач будет идентичный.

Вынесите общий функционал в третий класс и используйте как зависимость.

P.s. В копипасте кода нет ничего плохого. В копипасте логики - есть.