В чем косяк (полиморфизм)?

Question

[eskl]

Недавно ходил на собеседование и и меня попросили рассказать , что такое полиморфизм.
Ответил следующие.

class unit {
    public $hp = 'NaN';
    public function setHp (){
			return $this->hp = "30 hp";
    }
}
class warrior extends unit {
     public function setHp (){
         return $this->hp = "80 hp";
     }
}
class medic extends unit {
    public function setHp (){
        return $this->hp = "40 hp";
    }
}
class tank extends unit {
    public function setHp (){
        return $this->hp = "200 hp";
    }
}

$warrior = new warrior;
$medic = new medic;
$tank = new tank;
$unit = new unit;

echo $warrior->setHp();
echo $medic->setHp();
echo $tank->setHp();
echo $unit->setHp();

Тот , кто мне собеседовал , сказал , что это не правильно . ( гуглил в инете везде подобных примеров полным полно). В чем я ошибаюсь ?

Comments

[AtomKrieg]

Надо было спросить у работодателя

Answer 1

[xfg]

В программировании несколько различных видов полиморфизма. Вам следовало уточнить, о каком из них идет речь. Собеседующий с вами конечно же не совсем корректен, так как простейшая форма полиморфизма в вашем примере все же присутствует. Другое дело, что в php под полиморфизмом обычно понимают полиморфизм подтипов. Выглядит так

interface UnitInterface {
  public function setHp();
}
class Warrior implements UnitInterface {
  public function setHp() {...}
}
class Medic implements UnitInterface {
  public function setHp() {...}
}

class MainProgram {
  private $unit;

  public function __construct(UnitInterface $unit) {
    $this->unit = $unit;
  }
  public function run() {
    return $this->unit->setHp();
  }
}

echo (new MainProgram(new Warrior())->run();

Идея в том, что конструктор класса MainProgram ничего не знает о конкретных реализациях ваших юнитов. Он знает только о том, что они должны удовлетворять интерфейсу UnitInterface. В будущем если у вас хорошо спроектирован интерфейс, то вы сможете заменить одну реализацию юнита на другую, не изменяя код внутри MainProgram. Таким образом, вы соблюдаете принцип открытости/закрытости из SOLID, который говорит, что классы должны быть открыты для расширения, но закрыты для изменений.

Comments

[xfg]

MaxKorz: это уже ваше предположение, что метод будет одинаков. Моя задача показать, что такое полиморфизм подтипов на примере автора. Поэтому конкретная реализация классов не имеет никакого значения.

Полиморфизм = многообразный. Это значит, что вы не должны делать N правок. Каждая конкретная реализация интерфейса должна иметь своё собственное отличное от других поведение. Именно это я пытался донести. Если поведение всегда одинаково, то очевидно, что полиморфизм не нужен вообще. Собственно это нужно понимать, т.к. вопрос о полиморфизме, а не об архитектуре приложения.

я бы сделал так sandbox.onlinephpfunctions.com/code/3385d3ecb1d405...

Нет никакого смысла иметь абстрактный класс, без абстрактных методов.

Answer 2

[TheTalion]

Может стоило сделать абстрактным метод в unit, а потом его переопределять? Т.к. юнита отдельно мы не используем, поэтому реализацию функции для него нам знать не нужно. Нужно знать только наличие функции.

Answer 3

[Александр Аксентьев]

return $this->hp = "200 hp";
Конструкция какая-то неизвестная миру.
Почему return везде?
Почему возвращается присваивание?

Ну и логичнее наверно делать unit interface, а не класс.

Comments

[Adamos]

Миру такая конструкция известна. Результатом присваивания является присвоенное значение, и использование этого результата вполне корректно.
Нетрадиционное программирование тут заключается скорее в том, что функция, названная как сеттер, им не является.

Answer 4

[Алексей]

Если в вопросе предполагался параметрический полиморфизм, то его нужно было показать. Вы показали только наследование и создание объектов. Нужно было хотя бы загнать их в массив и в цикле делать setHp(). Тем самым показать что все равно какой там тип. unit можно заменить на интерфейс, и сделать какую-то внешнюю функцию которая бы требовала этот интерфейс, а вы туда передавали бы воинов и танков.