PHP: Ковариантность и контравариантность

Ковариантность и контравариантность

В PHP 7.2.0 путём снятия ограничений типа для параметров в дочернем методе добавили частичную контравариантность. Начиная с PHP 7.4.0 добавили полную поддержку ковариантности и контравариантности.

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

Объявление типа считают более конкретным в следующем случае:

Удалили тип из объединения типов
Добавили тип к пересечению типов
Тип класса изменили на тип дочернего класса
Тип iterable изменили на тип array или Traversable

Класс типа считают менее конкретным, если верно обратное.

Ковариантность

Создадим простой абстрактный родительский класс Animal, чтобы проиллюстрировать работу ковариантности. Класс Animal расширяется дочерними классами Cat и Dog.

<?php

abstract class Animal
{
    protected string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    abstract public function speak();
}

class Dog extends Animal
{
    public function speak()
    {
        echo $this->name . " лает";
    }
}

class Cat extends Animal
{
    public function speak()
    {
        echo $this->name . " мяукает";
    }
}

?>

Обратите внимание, пример не содержит методов, которые возвращают значения. Добавим ряд фабрик, которые возвращают новый объект с типом класса Animal, Cat или Dog.

<?php

interface AnimalShelter
{
    public function adopt(string $name): Animal;
}

class CatShelter implements AnimalShelter
{
    public function adopt(string $name): Cat // Возвращаем тип Cat вместо типа Animal
    {
        return new Cat($name);
    }
}

class DogShelter implements AnimalShelter
{
    public function adopt(string $name): Dog // Возвращаем тип Dog вместо типа Animal
    {
        return new Dog($name);
    }
}

$kitty = (new CatShelter())->adopt("Рыжик");
$kitty->speak();
echo "\n";

$doggy = (new DogShelter())->adopt("Бобик");
$doggy->speak();

?>

Результат выполнения приведённого примера:

Рыжик мяукает
Бобик лает

Контравариантность

В продолжение предыдущего примера с классами Animal, Cat и Dog введём новые классы — Food и AnimalFood, и добавим в абстрактный класс Animal новый метод eat(AnimalFood $food).

<?php

class Food {}

class AnimalFood extends Food {}

abstract class Animal
{
    protected string $name;

    public function __construct(string $name)
    {
        $this->name = $name;
    }

    public function eat(AnimalFood $food)
    {
        echo $this->name . " ест " . get_class($food);
    }
}

?>

Переопределим метод eat в классе Dog так, чтобы метод принимал любой объект с типом Food, чтобы увидеть суть контравариантности. Класс Cat оставим без изменений.

<?php

class Dog extends Animal
{
    public function eat(Food $food)
    {
        echo $this->name . " ест " . get_class($food);
    }
}

?>

Следующий пример покажет поведение контравариантности.

<?php

$kitty = (new CatShelter())->adopt("Рыжик");
$catFood = new AnimalFood();
$kitty->eat($catFood);
echo "\n";

$doggy = (new DogShelter())->adopt("Бобик");
$banana = new Food();
$doggy->eat($banana);

?>

Результат выполнения приведённого примера:

Рыжик ест AnimalFood
Бобик ест Food

Но что произойдёт, если кошка $kitty попробует методом eat() съесть банан $banana?

$kitty->eat($banana);

Результат выполнения приведённого примера:

Fatal error: Uncaught TypeError: Argument 1 passed to Animal::eat() must be an instance of AnimalFood, instance of Food given

Вариативность свойств

По умолчанию свойства не удовлетворяют ни правилам ковариантности, ни правилам контравариантности, следовательно, свойства — инвариантны. Поэтому тип свойства вообще нельзя изменить в дочернем классе. Причина этого состоит в том, что операции «чтения» должны быть ковариантными, а операции «записи» — контравариантными. Единственный доступный для свойства способ удовлетворить обоим требованиям — оставаться инвариантным.

Начиная с PHP 8.4.0, в котором добавили абстрактные свойства в интерфейсе или абстрактном классе и виртуальные свойства, разрешается объявить свойство, доступное только для операций чтения или записи. Итогом нововведений стало то, что абстрактным свойствам или виртуальным свойствам, для которых требуется только операция "get", доступна ковариантность. Аналогично, абстрактному свойству или виртуальному свойству, для которого требуется только операция "set", доступна контравариантность.

Однако как только для свойства объявили как операцию get, так и операцию set, свойство теряет ковариантность или контравариантность для расширения, и снова становится инвариантным.

Пример #1 Пример вариативности типа свойства

<?php

class Animal {}
class Dog extends Animal {}
class Poodle extends Dog {}

interface PetOwner
{
    // Требуется только операция get, поэтому свойству доступна ковариантность
    public Animal $pet {
        get;
    }
}

class DogOwner implements PetOwner
{
    // Свойству возможно указать более ограниченный тип, поскольку со стороны операции get
    // по-прежнему возвращается Animal. Однако, поскольку это внутреннее свойство текущего класса,
    // потомкам класса больше нельзя изменять тип свойства
    public Dog $pet;
}

class PoodleOwner extends DogOwner
{
    // Изменение свойства НЕДОПУСТИМО, поскольку для свойства DogOwner::$pet
    // определили поведение операций get и set, и дочерние классы обязаны соблюдать
    // контракт родительского класса при переопределении свойства
    public Poodle $pet;
}

?>

Нашли ошибку?

Инструкция • Исправление • Сообщение об ошибке

＋Добавить

Примечания пользователей 3 notes

down

xedin dot unknown at gmail dot com ¶

4 years ago

I would like to explain why covariance and contravariance are important, and why they apply to return types and parameter types respectively, and not the other way around.

Covariance is probably easiest to understand, and is directly related to the Liskov Substitution Principle. Using the above example, let's say that we receive an `AnimalShelter` object, and then we want to use it by invoking its `adopt()` method. We know that it returns an `Animal` object, and no matter what exactly that object is, i.e. whether it is a `Cat` or a `Dog`, we can treat them the same. Therefore, it is OK to specialize the return type: we know at least the common interface of any thing that can be returned, and we can treat all of those values in the same way.

Contravariance is slightly more complicated. It is related very much to the practicality of increasing the flexibility of a method. Using the above example again, perhaps the "base" method `eat()` accepts a specific type of food; however, a _particular_ animal may want to support a _wider range_ of food types. Maybe it, like in the above example, adds functionality to the original method that allows it to consume _any_ kind of food, not just that meant for animals. The "base" method in `Animal` already implements the functionality allowing it to consume food specialized for animals. The overriding method in the `Dog` class can check if the parameter is of type `AnimalFood`, and simply invoke `parent::eat($food)`. If the parameter is _not_ of the specialized type, it can perform additional or even completely different processing of that parameter - without breaking the original signature, because it _still_ handles the specialized type, but also more. That's why it is also related closely to the Liskov Substitution: consumers may still pass a specialized food type to the `Animal` without knowing exactly whether it is a `Cat` or `Dog`.

down

Hayley Watson ¶

2 years ago

The gist of how the Liskov Substition Princple applies to class types is, basically: "If an object is an instance of something, it should be possible to use it wherever an instance of something is allowed". The Co- and Contravariance rules come from this expectation when you remember that "something" could be a parent class of the object.

For the Cat/Animal example of the text, Cats are Animals, so it should be possible for Cats to go anywhere Animals can go. The variance rules formalise this.

Covariance: A subclass can override a method in the parent class with one that has a narrower return type. (Return values can be more specific in more specific subclasses; they "vary in the same direction", hence "covariant").
If an object has a method you expect to produce Animals, you should be able to replace it with an object where that method produces only Cats. You'll only get Cats from it but Cats are Animals, which are what you expected from the object.

Contravariance: A subclass can override a method in the parent class with one that has a parameter with a wider type. (Parameters can be less specific in more specific subclasses; they "vary in the opposite direction", hence "contravariant").
If an object has a method you expect to take Cats, you should be able to replace it with an object where that method takes any sort of Animal. You'll only be giving it Cats but Cats are Animals, which are what the object expected from you.

So, if your code is working with an object of a certain class, and it's given an instance of a subclass to work with, it shouldn't cause any trouble:
It might accept any sort of Animal where you're only giving it Cats, or it might only return Cats when you're happy to receive any sort of Animal, but LSP says "so what? Cats are Animals so you should both be satisfied."

down

Anonymous ¶

4 years ago

Covariance also works with general type-hinting, note also the interface:

interface xInterface
{
    public function y() : object;
}

abstract class x implements xInterface
{
    abstract public function y() : object;
}

class a extends x
{
    public function y() : \DateTime
    {
        return new \DateTime("now");
    }
}

$a = new a;
echo '<pre>';
var_dump($a->y());
echo '</pre>';

＋Добавить