Что такое PECS (продюсер расширяет потребительскую ценность)?

tl; dr: PECS с точки зрения коллекции. Если вы только извлекаете элементы из общей коллекции, это производитель, и вам следует использовать extends; если вы только набиваете элементы, это потребитель, и вам следует использовать super. Если вы делаете и то, и другое с одной и той же коллекцией, вам не следует использовать ни extends, ни super.

Предположим, у вас есть метод, который принимает в качестве параметра набор вещей, но вы хотите, чтобы он был более гибким, чем просто принятие Collection<Thing>.

Случай 1. Вы хотите просмотреть коллекцию и выполнить действия с каждым элементом.
Тогда список является производителем, поэтому вам следует использовать Collection<? extends Thing>.

Причина в том, что Collection<? extends Thing> может содержать любой подтип Thing, и поэтому каждый элемент будет вести себя как Thing, когда вы выполняете свою операцию. (На самом деле вы не можете ничего добавить (кроме нуля) к Collection<? extends Thing>, потому что во время выполнения вы не можете узнать, какой конкретный подтип Thing содержится в коллекции.)

Случай 2: вы хотите добавить объекты в коллекцию.
Тогда список является потребителем, поэтому вам следует использовать Collection<? super Thing>.

Причина здесь в том, что в отличие от Collection<? extends Thing>, Collection<? super Thing> всегда может содержать Thing независимо от фактического параметризованного типа. Здесь вам все равно, что уже есть в списке, если это позволяет добавить Thing; это то, что ? super Thing гарантирует.

Принципы, лежащие в основе этого в информатике, называются

• Ковариация: ? extends MyClass,
• Контравариантность: ? super MyClass и
• Инвариантность / отсутствие дисперсии: MyClass

Изображение ниже должно объяснить концепцию. Изображение предоставлено: Андрей Тюкин

PECS (производитель extends и потребитель super)

мнемоника → Получить и положить принцип.

Этот принцип гласит:

• Используйте подстановочный знак extends, когда вы получаете значения только из структуры.
• Используйте подстановочный знак super, когда вы помещаете только значения в структуру.
• И не используйте подстановочный знак, когда вы одновременно получаете и вставляете.

Пример на Java:

class Super {
        Number testCoVariance() {
            return null;
        }
        void testContraVariance(Number parameter) {
        } 
    }
    
    class Sub extends Super {
        @Override
        Integer testCoVariance() {
            return null;
        } //compiles successfully i.e. return type is don't care(Integer is subtype of Number)
        @Override
        void testContraVariance(Integer parameter) {
        } //doesn't support even though Integer is subtype of Number
    }

Принцип подстановки Лискова (LSP) гласит, что «объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы».

В системе типов языка программирования правило типизации

• ковариантный, если он сохраняет порядок типов (≤), который упорядочивает типы от более конкретных к более общим;
• контравариантный, если он меняет порядок следования;
• инвариантный или невариантный, если ни одно из этих условий не применимо.

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

• Типы данных (источники), доступные только для чтения, могут быть ковариантными. ;
• типы данных (приемники) только для записи могут быть контравариантными.
• Изменяемые типы данных, которые действуют как источники и приемники, должны быть инвариантными.

Чтобы проиллюстрировать это общее явление, рассмотрим тип массива. Для типа Animal мы можем сделать тип Animal []

• ковариантный: кошка [] - это животное [];
• контравариант: животное [] - это кошка [];
• инвариант: животное [] не является кошкой [], а кошка [] не является животным [].

Примеры Java:

Object name= new String("prem"); //works
List<Number> numbers = new ArrayList<Integer>();//gets compile time error

Integer[] myInts = {1,2,3,4};
Number[] myNumber = myInts;
myNumber[0] = 3.14; //attempt of heap pollution i.e. at runtime gets java.lang.ArrayStoreException: java.lang.Double(we can fool compiler but not run-time)

List<String> list=new ArrayList<>();
list.add("prem");
List<Object> listObject=list; //Type mismatch: cannot convert from List<String> to List<Object> at Compiletime  

другие примеры

Источник изображения

ограниченный (т. е. направление куда-то) подстановочный знак: существует 3 разных вида подстановочных знаков:

• Несоответствие / отсутствие отклонения: ? или ? extends Object - Неограниченный подстановочный знак. Это символ семьи всех типов. Используйте, когда вы и достаете, и кладете.
• Совместная дисперсия: ? extends T (Правление T потомков) - подстановочный знак с верхней границей. T - это самый верхний класс в иерархии наследования. Используйте подстановочный знак extends, когда вы только получаете значения из структуры.
• Противоположная дисперсия: ? super T (Правление T предка) - подстановочный знак с нижней границей. T - это самый нижний класс в иерархии наследования. Используйте подстановочный знак super, если в структуру вы только помещаете значения.

Примечание. Подстановочный знак ? означает ноль или один раз, представляет неизвестный тип. Подстановочный знак может использоваться как тип параметра, никогда не использоваться как аргумент типа для вызова универсального метода, создания экземпляра универсального класса (т. Е. Когда используется подстановочный знак, ссылка на который не используется где-либо еще в программе, как мы используем T)

 import java.util.ArrayList;
import java.util.List;

class Shape { void draw() {}}

class Circle extends Shape {void draw() {}}

class Square extends Shape {void draw() {}}

class Rectangle extends Shape {void draw() {}}

public class Test {

    public static void main(String[] args) {
        //? extends Shape i.e. can use any sub type of Shape, here Shape is Upper Bound in inheritance hierarchy
        List<? extends Shape> intList5 = new ArrayList<Shape>();
        List<? extends Shape> intList6 = new ArrayList<Cricle>();
        List<? extends Shape> intList7 = new ArrayList<Rectangle>();
        List<? extends Shape> intList9 = new ArrayList<Object>();//ERROR.


        //? super Shape i.e. can use any super type of Shape, here Shape is Lower Bound in inheritance hierarchy
        List<? super Shape> inList5 = new ArrayList<Shape>();
        List<? super Shape> inList6 = new ArrayList<Object>();
        List<? super Shape> inList7 = new ArrayList<Circle>(); //ERROR.

        //-----------------------------------------------------------
        Circle circle = new Circle();
        Shape shape = circle; // OK. Circle IS-A Shape

        List<Circle> circles = new ArrayList<>();
        List<Shape> shapes = circles; // ERROR. List<Circle> is not subtype of List<Shape> even when Circle IS-A Shape

        List<? extends Circle> circles2 = new ArrayList<>();
        List<? extends Shape> shapes2 = circles2; // OK. List<? extends Circle> is subtype of List<? extends Shape>


        //-----------------------------------------------------------
        Shape shape2 = new Shape();
        Circle circle2= (Circle) shape2; // OK. with type casting

        List<Shape> shapes3 = new ArrayList<>();
        List<Circle> circles3 = shapes3; //ERROR. List<Circle> is not subtype of  List<Shape> even Circle is subetype of Shape

        List<? super Shape> shapes4 = new ArrayList<>();
        List<? super Circle> circles4 = shapes4; //OK.
    }

    
    
    /*
     * Example for an upper bound wildcard (Get values i.e Producer `extends`)
     *
     * */
    public void testCoVariance(List<? extends Shape> list) {
        list.add(new Object());//ERROR
        list.add(new Shape()); //ERROR
        list.add(new Circle()); // ERROR
        list.add(new Square()); // ERROR
        list.add(new Rectangle()); // ERROR
        Shape shape= list.get(0);//OK so list act as produces only
    /*
     * You can't add a Shape,Circle,Square,Rectangle to a List<? extends Shape>
     * You can get an object and know that it will be an Shape
     */
    }
    
    
    /*
     * Example for  a lower bound wildcard (Put values i.e Consumer`super`)
     * */
    public void testContraVariance(List<? super Shape> list) {
        list.add(new Object());//ERROR
        list.add(new Shape());//OK
        list.add(new Circle());//OK
        list.add(new Square());//OK
        list.add(new Rectangle());//OK
        Shape shape= list.get(0); // ERROR. Type mismatch, so list acts only as consumer
        Object object= list.get(0); //OK gets an object, but we don't know what kind of Object it is.
        /*
         * You can add a Shape,Circle,Square,Rectangle to a List<? super Shape>
         * You can't get an Shape(but can get Object) and don't know what kind of Shape it is.
         */
    }
}

дженерики и примеры

Ковариация и контравариантность определяют совместимость на основе по типам. В любом случае дисперсия - это направленное отношение. Ковариация может быть переведена как разные в одном направлении или с разными, тогда как контравариантность означает разные в противоположном направлении или против разных. Ковариантный и контравариантный типы - это не одно и то же, но между ними существует взаимосвязь. Имена подразумевают направление корреляции.

https://stackoverflow.com/a/54576828/1697099
https://stackoverflow.com/a/64888058/1697099

• Ковариация: принять подтипы (только чтение, т. Е. Производитель)
• Контравариантность: принимать супертипы (только писать, т. Е. Потребитель)

Вкратце, три простых правила, которые нужно запомнить PECS:

1. Используйте подстановочный знак <? extends T>, если вам нужно получить объект типа T из коллекции.
2. Используйте подстановочный знак <? super T>, если вам нужно поместить объекты типа T в коллекцию.
3. Если вам нужно удовлетворить оба требования, не используйте подстановочные знаки. Так просто.

Как я объясняю в моем ответе на другой вопрос, PECS - это мнемоническое устройство, созданное Джошем Блохом, чтобы помочь запомнить P разработчик extends, C потребителя super.

Это означает, что когда параметризованный тип, передаваемый методу, создает экземпляры T (они будут извлечены из него каким-либо образом), следует использовать ? extends T, поскольку любой экземпляр подкласса T является также T.

Когда параметризованный тип, передаваемый методу, будет потреблять экземпляры T (они будут переданы ему для выполнения каких-либо действий), следует использовать ? super T, потому что экземпляр T может быть законно передан любому методу, который принимает некоторый супертип T. Например, Comparator<Number> можно использовать на Collection<Integer>. ? extends T не будет работать, потому что Comparator<Integer> не может работать с Collection<Number>.

Обратите внимание, что обычно вы должны использовать только ? extends T и ? super T для параметров какого-либо метода. Методы должны просто использовать T в качестве параметра типа для универсального возвращаемого типа.

предположим эту иерархию:

class Creature{}// X
class Animal extends Creature{}// Y
class Fish extends Animal{}// Z
class Shark extends Fish{}// A
class HammerSkark extends Shark{}// B
class DeadHammerShark extends HammerSkark{}// C

Давайте проясним PE - Производитель расширяется:

List<? extends Shark> sharks = new ArrayList<>();

Почему в этот список нельзя добавлять объекты, расширяющие «Акулу»? нравиться:

sharks.add(new HammerShark());//will result in compilation error

Поскольку у вас есть список, который может быть типа A, B или C во время выполнения, вы не можете добавить в него какой-либо объект типа A, B или C, потому что вы можете получить комбинацию, которая не является разрешено в java.
На практике компилятор действительно может видеть во время компиляции, что вы добавляете B:

sharks.add(new HammerShark());

... но у него нет способа определить, будет ли во время выполнения ваш B подтипом или супертипом типа списка. Во время выполнения тип списка может быть любым из типов A, B, C. Таким образом, вы не можете добавить HammerSkark (супертип), например, в список DeadHammerShark.

* Вы скажете: «Хорошо, но почему я не могу добавить в него HammerSkark, ведь это самый маленький тип?». Ответ: Это самый маленький из известных вам. Но HammerSkark может быть расширен кем-то другим, и вы попадете в тот же сценарий.

Давайте проясним CS - Consumer Super:

В той же иерархии мы можем попробовать это:

List<? super Shark> sharks = new ArrayList<>();

Что и почему вы можете добавить в этот список?

sharks.add(new Shark());
sharks.add(new DeadHammerShark());
sharks.add(new HammerSkark());

Вы можете добавить объекты вышеупомянутых типов, потому что все, что ниже акулы (A, B, C), всегда будет подтипом всего, что находится выше акулы (X, Y, Z). Легко понять.

Вы не можете добавлять типы выше Shark, потому что во время выполнения тип добавляемого объекта может быть выше по иерархии, чем объявленный тип списка (X, Y, Z). Это не разрешено.

Но почему вы не можете читать из этого списка? (Я имею в виду, что вы можете получить из него элемент, но вы не можете назначить его ничему, кроме Object o):

Object o;
o = sharks.get(2);// only assignment that works

Animal s;
s = sharks.get(2);//doen't work

Во время выполнения тип списка может быть любым типом выше A: X, Y, Z, ... Компилятор может скомпилировать ваш оператор присваивания (что кажется правильным), но во время выполнения тип s (Животное) может быть ниже по иерархии, чем объявленный тип списка (это может быть Существо или выше). Это не разрешено.

Подводя итоги

Мы используем <? super T> для добавления объектов типов, равных или ниже T к List. Мы не можем читать из него.
Мы используем <? extends T> для чтения объектов типов, равных или ниже T из списка. Мы не можем добавить к нему элемент.

Это самый ясный и простой способ подумать о расширениях и супер:

• extends предназначен для чтения

• super предназначен для письма

Я считаю, что «PECS» - неочевидный способ думать о вещах, касающихся того, кто является «производителем», а кто «потребителем». "PECS" определяется с точки зрения самой коллекции данных - коллекция "потребляет", если в нее записываются объекты (она потребляет объекты из вызывающего кода), и он «производит», если объекты считываются из (он создает объекты для некоторого вызывающего кода). Это противоречит тому, как все остальное названо. Стандартные API Java именуются с точки зрения вызывающего кода, а не самой коллекции. Например, ориентированный на коллекцию вид java.util. В списке должен быть метод с именем «receive ()» вместо «add ()» - в конце концов, вызывающий код добавляет элемент, но сам список получает элемент.