What is PECS Producer Extends Consumer Super

Question

I came across PECS  short for Producer extends and Consumer super  while reading up on generics    Can someone explain to me how to use PECS to resolve confusion between extends and super

User · Answer

Remember this       Consumer eat supper super   Producer extends his parent s factory

User · Answer

let   s try visualizing this concept   lt   super SomeType gt  is an    undefined yet     type  but that undefined type should be a superclass of the    SomeType    class  The same goes for  lt   extends SomeType gt   It   s a type that should extend the    SomeType    class  it should be a child class of the    SomeType    class   If we consider the concept of  class inheritance  in a Venn diagram  an example would be like this   Mammal class extends Animal class  Animal class is a superclass of Mammal class   Cat Dog class extends Mammal class  Mammal class is a superclass of Cat Dog class   Then  let   s think about the    circles    in the above diagram as a    box    that has a physical volume   You CAN   T put a bigger box into a smaller one  You can ONLY put a smaller box into a bigger one  When you say  lt   super SomeType gt   you wanna describe a    box    that is the same size or bigger than the    SomeType    box  If you say  lt   extends SomeType gt   then you wanna describe a    box    that is the same size or smaller than the    SomeType    box  so what is PECS anyway  An example of a    Producer    is a List which we only read from  An example of a    Consumer    is a List which we only write into  Just keep in mind this   We    read    from a    producer     and take that stuff into our own box   And we    write    our own box into a    consumer       So  we need to read take  something from a    producer    and put that into our    box     This means that any boxes taken from the producer should NOT be bigger than our    box     That   s why    Producer Extends        Extends    means a smaller box smaller circle in the Venn diagram above   The boxes of a producer should be smaller than our own box  because we are gonna take those boxes from the producer and put them into our own box  We can   t put anything bigger than our box  Also  we need to write put  our own    box    into a    consumer     This means that the boxes of the consumer should NOT be smaller than our own box  That   s why    Consumer Super        Super    means a bigger box bigger circle in the Venn diagram above   If we want to put our own boxes into a consumer  the boxes of the consumer should be bigger than our box  Now we can easily understand this example  public class Collections      public static  lt T gt  void copy List lt   super T gt  dest  List lt   extends T gt  src          for  int i   0  i  lt  src size    i             dest set i  src get i             In the above example  we want to read take  something from src and write put  them into dest  So the src is a    Producer    and its    boxes    should be smaller more specific  than some type T  Vice versa  the dest is a    Consumer    and its    boxes    should be bigger more general  than some type T  If the    boxes    of the src were bigger than that of the dest  we couldn   t put those big boxes into the smaller boxes the dest has  If anyone reads this  I hope it helps you better understand    Producer Extends  Consumer Super     Happy coding

User · Answer

The PECS  rule  just ensures that the following is legal    Consumer  whatever   is  it can legally refer to T  Producer  whatever   is  it can legally be referred to by T   The typical pairing along the lines of List lt   extends T gt  producer  List lt   super T gt  consumer is simply ensuring that the compiler can enforce the standard  IS-A  inheritance relationship rules  If we could do so legally  it might be simpler to say  lt T extends   gt    lt   extends T gt   or better yet in Scala  as you can see above  it s  -T     T   Unfortunately the best we can do is  lt   super T gt    lt   extends T gt    When I first encountered this and broke it down in my head the mechanics made sense but the code itself continued to look confusing to me - I kept thinking  it seems like the bounds shouldn t need to be inverted like that  - even though I was clear on the above - that it s simply about guaranteeing compliance with the standard rules of reference   What helped me was looking at it using ordinary assignment as an analogy    Consider the following  not production ready  toy code      copies the elements of  producer  into  consumer  static  lt T gt  void copy List lt   extends T gt  producer  List lt   super T gt  consumer       for T t   producer         consumer add t       Illustrating this in terms of the assignment analogy  for consumer the   wildcard  unknown type  is the reference - the  left hand side  of the assignment - and  lt   super T gt  ensures that whatever   is  T  IS-A    - that T can be assigned to it  because   is a super type  or at most the same type  as T   For producer the concern is the same it s just inverted  producer s   wildcard  unknown type  is the referent - the  right hand side  of the assignment - and  lt   extends T gt  ensures that whatever   is     IS-A  T - that it can be assigned to a T  because   is a sub type  or at least the same type  as T

User · Answer

This is the clearest  simplest way for me think of extends vs  super    extends is for reading super is for writing   I find  PECS  to be a non-obvious way to think of things regarding who is the  producer  and who is the  consumer    PECS  is defined from the perspective of the data collection itself     the collection  consumes  if objects are being written to it  it is consuming objects from calling code   and it  produces  if objects are being read from it  it is producing objects to some calling code   This is counter to how everything else is named though  Standard Java APIs are named from the perspective of the calling code  not the collection itself  For example  a collection-centric view of java util List should have a method named  receive    instead of  add        after all  the calling code adds the element  but the list itself receives the element   I think it s more intuitive  natural and consistent to think of things from the perspective of the code that interacts with the collection     does the code  read from  or  write to  the collection  Following that  any code writing to the collection would be the  producer   and any code reading from the collection would be the  consumer

User · Answer

In a nutshell  three easy rules to remember PECS     Use the  lt   extends T gt  wildcard if you need to retrieve object of type T from a collection  Use the  lt   super T gt  wildcard if you need to put objects of type T in a collection  If you need to satisfy both things  well  don   t use any wildcard  As simple as that

User · Answer

As I explain in my answer to another question  PECS is a mnemonic device  created by Josh Bloch to help remember Producer extends  Consumer super   This means that when a parameterized type being passed to a method will produce instances of T  they will be retrieved from it in some way     extends T should be used  since any instance of a subclass of T is also a T  When a parameterized type being passed to a method will consume instances of T  they will be passed to it to do something     super T should be used because an instance of T can legally be passed to any method that accepts some supertype of T  A Comparator lt Number gt  could be used on a Collection lt Integer gt   for example    extends T would not work  because a Comparator lt Integer gt  could not operate on a Collection lt Number gt    Note that generally you should only be using   extends T and   super T for the parameters of some method  Methods should just use T as the type parameter on a generic return type

User · Answer

Covariance and contravariance  Lets take a look at example public class A       B is A public class B extends A       C is A public class C extends A      Generics allows you to work with Types dynamically in a safe way   ListA List lt A gt  listA   new ArrayList lt A gt        add listA add new A     listA add new B     listA add new C        get A a0   listA get 0   A a1   listA get 1   A a2   listA get 2      ListB List lt B gt  listB   new ArrayList lt B gt        add listB add new B        get B b0   listB get 0     Problem Since Java s Collection is a reference type as a result we have next issues  Problem  1   not compiled   danger of   adding   non-B objects using listA reference listA   listB     Swift s generic does not have such problem because Collection is Value type About  therefore a new collection is created Problem  2   not compiled   danger of   getting   non-B objects using listB reference listB   listA    The solution - Generic Wildcards Wildcard is a reference type feature and it can not be instantiated directly Solution  1  lt   super A gt  aka lower bound aka contravariance aka consumers guarantees that it is operates by A and all superclasses  that is why it is safe to add List lt   super A gt  listSuperA  listSuperA   listA  listSuperA   new ArrayList lt Object gt        add listSuperA add new A     listSuperA add new B        get Object o0   listSuperA get 0     Solution  2  lt   extends A gt  aka upper bound aka covariance aka producers guarantees that it is operates by A and all subclasses  that is why it is safe to get and cast List lt   extends A gt  listExtendsA  listExtendsA   listA  listExtendsA   listB     get A a0   listExtendsA get 0

User · Answer

PECS  Producer extends and Consumer super  mnemonic   Get and Put principle  This principle states that   Use an extends wildcard when you only get values out of a structure  Use a super wildcard when you only put values into a structure  And don   t use a wildcard when you both get and put   Example in 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        The Liskov Substitution Principle  LSP  states that    objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program     Within the type system of a programming language  a typing rule  covariant if it preserves the ordering of types      which orders types from more specific to more generic  contravariant if it reverses this ordering  invariant or nonvariant if neither of these applies   Covariance and contravariance  Read-only data types  sources  can be covariant  write-only data types  sinks  can be contravariant  Mutable data types which act as both sources and sinks should be invariant   To illustrate this general phenomenon  consider the array type  For the type Animal we can make the type Animal    covariant  a Cat   is an Animal    contravariant  an Animal   is a Cat    invariant  an Animal   is not a Cat   and a Cat   is not an Animal     Java Examples  Object name  new String  quot prem quot      works List lt Number gt  numbers   new ArrayList lt Integer gt      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 lt String gt  list new ArrayList lt  gt     list add  quot prem quot    List lt Object gt  listObject list    Type mismatch  cannot convert from List lt String gt  to List lt Object gt  at Compiletime    more examples  Image src bounded i e  heading toward somewhere  wildcard   There are 3 different flavours of wildcards   In-variance Non-variance    or   extends Object - Unbounded Wildcard  It stands for the family of  all types  Use when you both get and put  Co-variance    extends T  the family of all types that are subtypes of  T   - a wildcard with an upper bound  T is the upper-most class in the inheritance hierarchy  Use an extends wildcard when you only Get values out of a structure  Contra-variance    super T   the family of all types that are supertypes of  T   - a wildcard with a lower bound  T is the lower-most class in the inheritance hierarchy  Use a super wildcard when you only Put values into a structure   Note  wildcard   means zero or one time  represents an unknown type  The wildcard can be used as the type of a parameter  never used as a type argument for a generic method invocation  a generic class instance creation  i e  when used wildcard that reference not used in elsewhere in program like we use 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 lt   extends Shape gt  intList5   new ArrayList lt Shape gt             List lt   extends Shape gt  intList6   new ArrayList lt Cricle gt             List lt   extends Shape gt  intList7   new ArrayList lt Rectangle gt             List lt   extends Shape gt  intList9   new ArrayList lt Object gt      ERROR                super Shape i e  can use any super type of Shape  here Shape is Lower Bound in inheritance hierarchy         List lt   super Shape gt  inList5   new ArrayList lt Shape gt             List lt   super Shape gt  inList6   new ArrayList lt Object gt             List lt   super Shape gt  inList7   new ArrayList lt Circle gt       ERROR             -----------------------------------------------------------         Circle circle   new Circle            Shape shape   circle     OK  Circle IS-A Shape          List lt Circle gt  circles   new ArrayList lt  gt             List lt Shape gt  shapes   circles     ERROR  List lt Circle gt  is not subtype of List lt Shape gt  even when Circle IS-A Shape          List lt   extends Circle gt  circles2   new ArrayList lt  gt             List lt   extends Shape gt  shapes2   circles2     OK  List lt   extends Circle gt  is subtype of List lt   extends Shape gt              -----------------------------------------------------------         Shape shape2   new Shape            Circle circle2   Circle  shape2     OK  with type casting          List lt Shape gt  shapes3   new ArrayList lt  gt             List lt Circle gt  circles3   shapes3    ERROR  List lt Circle gt  is not subtype of  List lt Shape gt  even Circle is subetype of Shape          List lt   super Shape gt  shapes4   new ArrayList lt  gt             List lt   super Circle gt  circles4   shapes4    OK                                 Example for an upper bound wildcard  Get values i e Producer  extends                        public void testCoVariance List lt   extends Shape gt  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 lt   extends Shape gt         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 lt   super Shape gt  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 lt   super Shape gt             You can t get an Shape but can get Object  and don t know what kind of Shape it is                       generics and examples Covariance and contravariance determine compatibility based on types  In either case  variance is a directed relation  Covariance can be translated as  quot different in the same direction  quot  or with-different  whereas contravariance means  quot different in the opposite direction  quot  or against-different  Covariant and contravariant types are not the same  but there is a correlation between them  The names imply the direction of the correlation

User · Answer

adding an answer because never enough examples with Generics wildcards             Source         List lt Integer gt  intList   Arrays asList 1 2 3          List lt Double gt  doubleList   Arrays asList 2 78 3 14          List lt Number gt  numList   Arrays asList 1 2 2 78 3 14 5              Destination        List lt Integer gt  intList2   new ArrayList lt  gt            List lt Double gt  doublesList2   new ArrayList lt  gt            List lt Number gt  numList2   new ArrayList lt  gt                 Works         copyElements1 intList intList2              from int to int         copyElements1 doubleList doublesList2       from double to double        static  lt T gt  void copyElements1 Collection lt T gt  src  Collection lt T gt  dest            for T n   src               dest add n                                Let s try to copy intList to its supertype      copyElements1 intList numList2      error  method signature just says  T                                           and here the compiler is given                                           two types  Integer and Number                                            so which one shall it be           PECS to the rescue       copyElements2 intList numList2       possible           copy Integer    extends T  to its supertype  Number is super of Integer      private static  lt T gt  void copyElements2 Collection lt   extends T gt  src                                             Collection lt   super T gt  dest            for T n   src               dest add n

User · Answer

Using real life example  with some simplifications     Imagine a freight train with freight cars as analogy to a list  You can put a cargo in a freight car if the cargo has the same or smaller size than the freight car    lt   super FreightCarSize gt  You can unload a cargo from a freight car if you have enough place  more than the size of the cargo  in your depot    lt   extends DepotSize gt

User · Answer

Covariance  accept subtypes Contravariance  accept supertypes  Covariant types are read-only  while contravariant types are write-only

User · Answer

let s assume this hierarchy   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   Let s clarify PE - Producer Extends   List lt   extends Shark gt  sharks   new ArrayList lt  gt       Why you cannot add objects that extend  Shark  in this list  like   sharks add new HammerShark      will result in compilation error   Since you have a list that can be of type A  B or C at runtime  you cannot add any object of type A  B or C in it because you can end up with a combination that is not allowed in java  In practice  the compiler can indeed see at compiletime that you add a B   sharks add new HammerShark          but it has no way to tell if at runtime  your B will be a subtype or supertype of the list type  At runtime the list type can be any of the types A  B  C  So you cannot end up adding HammerSkark  super type  in a list of DeadHammerShark for example    You will say   OK  but why can t I add HammerSkark in it since it is the smallest type     Answer  It is the smallest you know  But HammerSkark can be extended too by somebody else and you end up in the same scenario   Let s clarify CS - Consumer Super   In the same hierarchy we can try this   List lt   super Shark gt  sharks   new ArrayList lt  gt       What and why you can add to this list   sharks add new Shark     sharks add new DeadHammerShark     sharks add new HammerSkark       You can add the above types of objects because anything below shark A B C  will always be subtypes of anything above shark  X Y Z   Easy to understand    You cannot add types above Shark  because at runtime the type of added object can be higher in hierarchy than the declared type of the list X Y Z   This is not allowed   But why you cannot read from this list   I mean you can get an element out of it  but you cannot assign it to anything other than Object o    Object o  o   sharks get 2     only assignment that works  Animal s  s   sharks get 2    doen t work   At runtime  the type of list can be any type above A  X  Y  Z      The compiler can compile your assignment statement  which seems correct  but  at runtime the type of s  Animal  can be lower in hierarchy than the declared type of the list which could be Creature  or higher   This is not allowed   To sum up  We use  lt   super T gt  to add objects of types equal or below T to the List  We cannot read from  it  We use  lt   extends T gt  to read objects of types equal or below T from list  We cannot add element to it

User · Answer

The principles behind this in computer science is called   Covariance    extends MyClass  Contravariance    super MyClass and Invariance non-variance  MyClass   The picture below should explain the concept  Picture courtesy  Andrey Tyukin

User · Answer

tl dr   quot PECS quot  is from the collection s point of view  If you are only pulling items from a generic collection  it is a producer and you should use extends  if you are only stuffing items in  it is a consumer and you should use super  If you do both with the same collection  you shouldn t use either extends or super   Suppose you have a method that takes as its parameter a collection of things  but you want it to be more flexible than just accepting a Collection lt Thing gt   Case 1  You want to go through the collection and do things with each item  Then the list is a producer  so you should use a Collection lt   extends Thing gt   The reasoning is that a Collection lt   extends Thing gt  could hold any subtype of Thing  and thus each element will behave as a Thing when you perform your operation   You actually cannot add anything  except null  to a Collection lt   extends Thing gt   because you cannot know at runtime which specific subtype of Thing the collection holds   Case 2  You want to add things to the collection  Then the list is a consumer  so you should use a Collection lt   super Thing gt   The reasoning here is that unlike Collection lt   extends Thing gt   Collection lt   super Thing gt  can always hold a Thing no matter what the actual parameterized type is  Here you don t care what is already in the list as long as it will allow a Thing to be added  this is what   super Thing guarantees

User · Answer

public class Test        public class A         public class B extends A         public class C extends B         public void testCoVariance List lt   extends B gt  myBlist            B b   new B            C c   new C            myBlist add b      does not compile         myBlist add c      does not compile         A a   myBlist get 0               public void testContraVariance List lt   super B gt  myBlist            B b   new B            C c   new C            myBlist add b           myBlist add c           A a   myBlist get 0      does not compile

[java] What is PECS (Producer Extends Consumer Super)?

Examples related to java

Examples related to generics

Examples related to super

Examples related to bounded-wildcard

Examples related to pecs