Is Java's collections interface and class hierarchy ill done?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
6
down vote

favorite
1












I came to know that in Java, LinkedList class implements both Deque and List interfaces.
And this was somewhat confusing to me. In computer science syllabus, I was never taught that queue can be a list, or more precisely queue can behave like a list. That is, there are stuffs that lists can do, but queues cant. But the list can behave like a queue. For example, List interface has following methods:



add(E e)
add(int index, E element)


But Queue has only following:



add(E e)


So clearly Queue is not allowed to insert at specific index, which is allowed in List. Same is the case with other operations like Queue.remove() vs List.remove(int index), List.get(int index) vs Queue.peek().
In other words, list is more generalized data structure and can emulate Queue.



Now being capable to emulate is different from having contract subset. That is Queue disallows certain operations (indexing) of Listand allows certain operations done only in particular manner (insert only at tail and remove only from head). So Queue does not really do "addition" to the contracts of List. That is precisely why Queue does not extend List in Java collections framework, but both extend Collection interface. I believe that is also why its incorrect for any class to implement both, as Queue's contract conflicts with the contract of List (which is why they fork out from Collection interface separately). However, LinkedList implements both the interfaces.



I also came across this answer:




The LinkedList implementation happens to satisfy the Deque contract, so why not make it implement the interface?




I still dont get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of queue does not allow insertion at arbitrary index. Hence, the Queue interface does not have such methods. However we can only enforce contracts through interfaces and cannot disallow implementation of certain methods. Being list (having "List" in its name), I feel its not correct to have queue methods peek(), pop() and add(int index, E element) in LinkedList.



I believe, instead we should have separate class LinkedQueue which can have linked implementation for queue, similar to LinkedBlockingQueue which contains linked implementation of BlockingQueue.



Also note that LinkedList is the only class which inherits from both families of lists and queues, that is there is no other class which implements both List and Queue(, AFAIK). Can this be indication that LinkedList is ill done?



Am I plain wrong and thinking unnecessarily?






java collections







share|improve this question

















  • 4




    Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
    – pmcarpan
    3 hours ago











  • The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
    – Zabuza
    3 hours ago






  • 2




    The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
    – Zabuza
    3 hours ago











  • Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
    – Peter Lawrey
    2 hours ago














up vote
6
down vote

favorite
1












I came to know that in Java, LinkedList class implements both Deque and List interfaces.
And this was somewhat confusing to me. In computer science syllabus, I was never taught that queue can be a list, or more precisely queue can behave like a list. That is, there are stuffs that lists can do, but queues cant. But the list can behave like a queue. For example, List interface has following methods:



add(E e)
add(int index, E element)


But Queue has only following:



add(E e)


So clearly Queue is not allowed to insert at specific index, which is allowed in List. Same is the case with other operations like Queue.remove() vs List.remove(int index), List.get(int index) vs Queue.peek().
In other words, list is more generalized data structure and can emulate Queue.



Now being capable to emulate is different from having contract subset. That is Queue disallows certain operations (indexing) of Listand allows certain operations done only in particular manner (insert only at tail and remove only from head). So Queue does not really do "addition" to the contracts of List. That is precisely why Queue does not extend List in Java collections framework, but both extend Collection interface. I believe that is also why its incorrect for any class to implement both, as Queue's contract conflicts with the contract of List (which is why they fork out from Collection interface separately). However, LinkedList implements both the interfaces.



I also came across this answer:




The LinkedList implementation happens to satisfy the Deque contract, so why not make it implement the interface?




I still dont get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of queue does not allow insertion at arbitrary index. Hence, the Queue interface does not have such methods. However we can only enforce contracts through interfaces and cannot disallow implementation of certain methods. Being list (having "List" in its name), I feel its not correct to have queue methods peek(), pop() and add(int index, E element) in LinkedList.



I believe, instead we should have separate class LinkedQueue which can have linked implementation for queue, similar to LinkedBlockingQueue which contains linked implementation of BlockingQueue.



Also note that LinkedList is the only class which inherits from both families of lists and queues, that is there is no other class which implements both List and Queue(, AFAIK). Can this be indication that LinkedList is ill done?



Am I plain wrong and thinking unnecessarily?






java collections







share|improve this question

















  • 4




    Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
    – pmcarpan
    3 hours ago











  • The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
    – Zabuza
    3 hours ago






  • 2




    The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
    – Zabuza
    3 hours ago











  • Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
    – Peter Lawrey
    2 hours ago












up vote
6
down vote

favorite
1









up vote
6
down vote

favorite
1






1





I came to know that in Java, LinkedList class implements both Deque and List interfaces.
And this was somewhat confusing to me. In computer science syllabus, I was never taught that queue can be a list, or more precisely queue can behave like a list. That is, there are stuffs that lists can do, but queues cant. But the list can behave like a queue. For example, List interface has following methods:



add(E e)
add(int index, E element)


But Queue has only following:



add(E e)


So clearly Queue is not allowed to insert at specific index, which is allowed in List. Same is the case with other operations like Queue.remove() vs List.remove(int index), List.get(int index) vs Queue.peek().
In other words, list is more generalized data structure and can emulate Queue.



Now being capable to emulate is different from having contract subset. That is Queue disallows certain operations (indexing) of Listand allows certain operations done only in particular manner (insert only at tail and remove only from head). So Queue does not really do "addition" to the contracts of List. That is precisely why Queue does not extend List in Java collections framework, but both extend Collection interface. I believe that is also why its incorrect for any class to implement both, as Queue's contract conflicts with the contract of List (which is why they fork out from Collection interface separately). However, LinkedList implements both the interfaces.



I also came across this answer:




The LinkedList implementation happens to satisfy the Deque contract, so why not make it implement the interface?




I still dont get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of queue does not allow insertion at arbitrary index. Hence, the Queue interface does not have such methods. However we can only enforce contracts through interfaces and cannot disallow implementation of certain methods. Being list (having "List" in its name), I feel its not correct to have queue methods peek(), pop() and add(int index, E element) in LinkedList.



I believe, instead we should have separate class LinkedQueue which can have linked implementation for queue, similar to LinkedBlockingQueue which contains linked implementation of BlockingQueue.



Also note that LinkedList is the only class which inherits from both families of lists and queues, that is there is no other class which implements both List and Queue(, AFAIK). Can this be indication that LinkedList is ill done?



Am I plain wrong and thinking unnecessarily?






java collections







share|improve this question













I came to know that in Java, LinkedList class implements both Deque and List interfaces.
And this was somewhat confusing to me. In computer science syllabus, I was never taught that queue can be a list, or more precisely queue can behave like a list. That is, there are stuffs that lists can do, but queues cant. But the list can behave like a queue. For example, List interface has following methods:



add(E e)
add(int index, E element)


But Queue has only following:



add(E e)


So clearly Queue is not allowed to insert at specific index, which is allowed in List. Same is the case with other operations like Queue.remove() vs List.remove(int index), List.get(int index) vs Queue.peek().
In other words, list is more generalized data structure and can emulate Queue.



Now being capable to emulate is different from having contract subset. That is Queue disallows certain operations (indexing) of Listand allows certain operations done only in particular manner (insert only at tail and remove only from head). So Queue does not really do "addition" to the contracts of List. That is precisely why Queue does not extend List in Java collections framework, but both extend Collection interface. I believe that is also why its incorrect for any class to implement both, as Queue's contract conflicts with the contract of List (which is why they fork out from Collection interface separately). However, LinkedList implements both the interfaces.



I also came across this answer:




The LinkedList implementation happens to satisfy the Deque contract, so why not make it implement the interface?




I still dont get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of queue does not allow insertion at arbitrary index. Hence, the Queue interface does not have such methods. However we can only enforce contracts through interfaces and cannot disallow implementation of certain methods. Being list (having "List" in its name), I feel its not correct to have queue methods peek(), pop() and add(int index, E element) in LinkedList.



I believe, instead we should have separate class LinkedQueue which can have linked implementation for queue, similar to LinkedBlockingQueue which contains linked implementation of BlockingQueue.



Also note that LinkedList is the only class which inherits from both families of lists and queues, that is there is no other class which implements both List and Queue(, AFAIK). Can this be indication that LinkedList is ill done?



Am I plain wrong and thinking unnecessarily?






java collections




java collections






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 3 hours ago









anir

24319




24319







  • 4




    Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
    – pmcarpan
    3 hours ago











  • The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
    – Zabuza
    3 hours ago






  • 2




    The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
    – Zabuza
    3 hours ago











  • Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
    – Peter Lawrey
    2 hours ago












  • 4




    Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
    – pmcarpan
    3 hours ago











  • The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
    – Zabuza
    3 hours ago






  • 2




    The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
    – Zabuza
    3 hours ago











  • Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
    – Peter Lawrey
    2 hours ago







4




4




Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
– pmcarpan
3 hours ago





Linked List implements Deque and List. This does not mean that Deque is a List. Rather, both Deque and List can be implemented as a Linked List.
– pmcarpan
3 hours ago













The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
– Zabuza
3 hours ago




The datastructure, as LinkedList is currently written, represents a valid implementation for all those interfaces. So it is only natural to declare that it is all of them. You are wrong with your first paragraph. A Queue does in fact not have the methods a List has. But that is why we do not have Queue implements List. LinkedList is both of them, this does not imply that a Queue now is a List.
– Zabuza
3 hours ago




2




2




The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
– Zabuza
3 hours ago





The question is well asked though, so have my up-vote. Don't know why people are down-voting, maybe because they think it's silly (but that is no valid reason to down-vote).
– Zabuza
3 hours ago













Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
– Peter Lawrey
2 hours ago




Any interface doesn't prevent an implementation supporting more operations. (Except where overloaded methods conflict)
– Peter Lawrey
2 hours ago












2 Answers
2






active

oldest

votes

















up vote
15
down vote













You're entirely missing the point of programming to interface.



If you need a Queue, you never write:



LinkedList<String> queue = new LinkedList<>();


Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:



Queue<String> queue = new LinkedList<>();


Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.



So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.



  • LinkedList uses more memory, but shrinks when queue is emptied.


  • ArrayDeque uses less memory, but doesn't shrink.


  • PriorityQueue is a non-FIFO queue with element priority.


  • ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.


  • and more...



I was never taught that queue can be a list, or more precisely queue can behave like a list.




Remember that implements defines an behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.



But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.



The behaves like relation only goes one way.






share|improve this answer






















  • It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
    – anir
    2 hours ago











  • [...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
    – anir
    2 hours ago







  • 2




    @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
    – Andreas
    1 hour ago











  • Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
    – anir
    1 hour ago

















up vote
2
down vote













@Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:

In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list

A queue is not just any list but a special kind of list, with its own special properties and constraints.

That is, there are stuffs that lists can do, but queues cant.

No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.

But the list can behave like a queue.

No, List does not behave, it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.






share|improve this answer








New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • yup, good point!!!
    – anir
    2 hours ago










  • "A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
    – Andreas
    1 hour ago











  • @Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
    – forpas
    1 hour ago










  • If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
    – Andreas
    1 hour ago











  • @Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
    – forpas
    1 hour ago










Your Answer





StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52904106%2fis-javas-collections-interface-and-class-hierarchy-ill-done%23new-answer', 'question_page');

);

Post as a guest

















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
15
down vote













You're entirely missing the point of programming to interface.



If you need a Queue, you never write:



LinkedList<String> queue = new LinkedList<>();


Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:



Queue<String> queue = new LinkedList<>();


Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.



So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.



  • LinkedList uses more memory, but shrinks when queue is emptied.


  • ArrayDeque uses less memory, but doesn't shrink.


  • PriorityQueue is a non-FIFO queue with element priority.


  • ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.


  • and more...



I was never taught that queue can be a list, or more precisely queue can behave like a list.




Remember that implements defines an behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.



But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.



The behaves like relation only goes one way.






share|improve this answer






















  • It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
    – anir
    2 hours ago











  • [...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
    – anir
    2 hours ago







  • 2




    @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
    – Andreas
    1 hour ago











  • Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
    – anir
    1 hour ago














up vote
15
down vote













You're entirely missing the point of programming to interface.



If you need a Queue, you never write:



LinkedList<String> queue = new LinkedList<>();


Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:



Queue<String> queue = new LinkedList<>();


Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.



So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.



  • LinkedList uses more memory, but shrinks when queue is emptied.


  • ArrayDeque uses less memory, but doesn't shrink.


  • PriorityQueue is a non-FIFO queue with element priority.


  • ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.


  • and more...



I was never taught that queue can be a list, or more precisely queue can behave like a list.




Remember that implements defines an behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.



But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.



The behaves like relation only goes one way.






share|improve this answer






















  • It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
    – anir
    2 hours ago











  • [...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
    – anir
    2 hours ago







  • 2




    @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
    – Andreas
    1 hour ago











  • Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
    – anir
    1 hour ago












up vote
15
down vote










up vote
15
down vote









You're entirely missing the point of programming to interface.



If you need a Queue, you never write:



LinkedList<String> queue = new LinkedList<>();


Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:



Queue<String> queue = new LinkedList<>();


Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.



So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.



  • LinkedList uses more memory, but shrinks when queue is emptied.


  • ArrayDeque uses less memory, but doesn't shrink.


  • PriorityQueue is a non-FIFO queue with element priority.


  • ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.


  • and more...



I was never taught that queue can be a list, or more precisely queue can behave like a list.




Remember that implements defines an behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.



But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.



The behaves like relation only goes one way.






share|improve this answer














You're entirely missing the point of programming to interface.



If you need a Queue, you never write:



LinkedList<String> queue = new LinkedList<>();


Because, you're right, that would allow you to use non-queue methods. Instead, you program to the interface like this:



Queue<String> queue = new LinkedList<>();


Now you only have access to the 6 Queue methods (and all the Collection methods). So, even though LinkedList implements more methods, you no longer have access to them.



So, if you need a Queue, you choose the implementation of the Queue interface that best suits the performance, storage, and access characteristics you need, e.g.



  • LinkedList uses more memory, but shrinks when queue is emptied.


  • ArrayDeque uses less memory, but doesn't shrink.


  • PriorityQueue is a non-FIFO queue with element priority.


  • ConcurrentLinkedQueue, ConcurrentLinkedDeque supports multi-threaded concurrent access.


  • and more...



I was never taught that queue can be a list, or more precisely queue can behave like a list.




Remember that implements defines an behaves like relationship. A LinkedList behaves like a List. A LinkedList behaves like a Deque. A LinkedList behaves like a Queue.



But just because LinkedList behaves like all of those, doesn't mean that List behaves like a Queue or that Queue behaves like a List. They do not.



The behaves like relation only goes one way.







share|improve this answer














share|improve this answer



share|improve this answer








edited 1 hour ago

























answered 3 hours ago









Andreas

70.8k453111




70.8k453111











  • It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
    – anir
    2 hours ago











  • [...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
    – anir
    2 hours ago







  • 2




    @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
    – Andreas
    1 hour ago











  • Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
    – anir
    1 hour ago
















  • It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
    – anir
    2 hours ago











  • [...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
    – anir
    2 hours ago







  • 2




    @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
    – Andreas
    1 hour ago











  • Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
    – anir
    1 hour ago















It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
– anir
2 hours ago





It was difficult to swallow: "A LinkedList is a Deque. A LinkedList is a Queue." (In fact I havent yet.) I just checked wikipedia. It says: "Both stacks and queues are often implemented using linked lists, and simply restrict the type of operations which are supported". Also I can find push() and pop() methods in LinkedList. Now I feel implements is 'behaves like' relationship and extends defines 'is a' relationship. [continued...]
– anir
2 hours ago













[...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
– anir
2 hours ago





[...continued] It seems that the confusion was because I was attaching extends' 'is a' relationship meaning to implements. Am I right? Or still wrong?
– anir
2 hours ago





2




2




@anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
– Andreas
1 hour ago





@anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
– Andreas
1 hour ago













Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
– anir
1 hour ago




Now I am guessing why there is no Stack interface implemented by LinkedList as it also have push() and pop() methods. Surely it sounds wrong to do linkedListObj.push(). Is this something to do with java.util.Stack?
– anir
1 hour ago












up vote
2
down vote













@Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:

In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list

A queue is not just any list but a special kind of list, with its own special properties and constraints.

That is, there are stuffs that lists can do, but queues cant.

No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.

But the list can behave like a queue.

No, List does not behave, it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.






share|improve this answer








New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • yup, good point!!!
    – anir
    2 hours ago










  • "A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
    – Andreas
    1 hour ago











  • @Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
    – forpas
    1 hour ago










  • If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
    – Andreas
    1 hour ago











  • @Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
    – forpas
    1 hour ago














up vote
2
down vote













@Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:

In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list

A queue is not just any list but a special kind of list, with its own special properties and constraints.

That is, there are stuffs that lists can do, but queues cant.

No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.

But the list can behave like a queue.

No, List does not behave, it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.






share|improve this answer








New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

















  • yup, good point!!!
    – anir
    2 hours ago










  • "A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
    – Andreas
    1 hour ago











  • @Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
    – forpas
    1 hour ago










  • If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
    – Andreas
    1 hour ago











  • @Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
    – forpas
    1 hour ago












up vote
2
down vote










up vote
2
down vote









@Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:

In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list

A queue is not just any list but a special kind of list, with its own special properties and constraints.

That is, there are stuffs that lists can do, but queues cant.

No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.

But the list can behave like a queue.

No, List does not behave, it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.






share|improve this answer








New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









@Andreas's answer is excellent, so mine targets your arguments about what you were or were not taught:

In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list

A queue is not just any list but a special kind of list, with its own special properties and constraints.

That is, there are stuffs that lists can do, but queues cant.

No, List can do nothing. It provides possibilities to be implemented by a class and if that class decides to implement them then that class can do all that stuff.

But the list can behave like a queue.

No, List does not behave, it only suggests behaviors and classes that implement it can accept all or a subset of them or they can define new ones.







share|improve this answer








New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 2 hours ago









forpas

5426




5426




New contributor




forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






forpas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











  • yup, good point!!!
    – anir
    2 hours ago










  • "A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
    – Andreas
    1 hour ago











  • @Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
    – forpas
    1 hour ago










  • If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
    – Andreas
    1 hour ago











  • @Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
    – forpas
    1 hour ago
















  • yup, good point!!!
    – anir
    2 hours ago










  • "A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
    – Andreas
    1 hour ago











  • @Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
    – forpas
    1 hour ago










  • If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
    – Andreas
    1 hour ago











  • @Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
    – forpas
    1 hour ago















yup, good point!!!
– anir
2 hours ago




yup, good point!!!
– anir
2 hours ago












"A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
– Andreas
1 hour ago





"A queue is a special kind of list" Not always, e.g. a PriorityQueue is a heap, not a list. --- "List does not behave" That is about the only thing it does: Behave. The List interface is a contract of behavior, e.g. "if you call add(2, "X") the result must be that "X" is the third value in the list". Any class implementing the interface must "behave" the way the interface describes. It doesn't matter which class implements the List, the List will behave according to the contract.
– Andreas
1 hour ago













@Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
– forpas
1 hour ago




@Andreas The List interface is a contract of behavior you said it. List does not behave because it is not real, its implementations are real and can behave. As for the PriorityQueue: what I state in my answer is not Java specific, but rather academic. The concept of a priority queue and any queue is a subset of lists regardless how any language decides to implement its mechanics.
– forpas
1 hour ago












If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
– Andreas
1 hour ago





If my code has a List, it is very real. I may not know how it is realized (implemented), but if it wasn't real, I couldn't use it, and it behaves exactly like I expect. The List interface declaration defines a contract, but a list (an object of the List interface) is real and it behaves. --- My first comment was trying to say that your terminology is confusing / misleading.
– Andreas
1 hour ago













@Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
– forpas
1 hour ago




@Andreas so what are we arguing about? In my answer when I refer to List I mean the interface because this was OP's question. Of course an instantiated List object is real because it accepts and implements everything in the contract of behavior of the List interface.
– forpas
1 hour ago

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52904106%2fis-javas-collections-interface-and-class-hierarchy-ill-done%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

White Anglo-Saxon Protestant

Image
White Anglo-Saxon Protestants ( WASPs ) are a social group of wealthy and well-connected white Americans, of Protestant and predominantly British ancestry, who trace their ancestry to the American colonial period. Until at least the 1960s, this group has dominated American society and culture and dominated in the leadership of the Whig and Republican parties. They usually are very well placed in major financial, business, legal and academic institutions and had close to a monopoly of elite society due to intermarriage and nepotism. [1] During the latter half of the twentieth century, outsider ethnic and racial groups grew in influence and WASP dominance weakened. Americans are increasingly criticizing the WASP hegemony and disparaging WASPs as the epitome of "the Establishment". The Random House Unabridged Dictionary (1998) says the term is "Sometimes Disparaging and Offensive". [2] [3] The term WASP is often used as a pejorative to classify their historical dom...
Read more

BuddyTV

BuddyTV Owner David Niu, Andy Liu Created by Various contributors Website www.buddytv.com Launched July 31, 2007 Current status Offline BuddyTV was an entertainment-based website based in Seattle, Washington, which generated content about television programs and sporting events. The website published information about celebrity and related entertainment news through a series of articles, entertainment profiles, actor biographies and user forums. [1] On 31 December 2014, Smart TV manufacturer VIZIO acquired BuddyTV's parent Advanced Media Research Group, Inc., in order to expand content and service offerings. [2] The site was shut down on 22 May 2018. [3] Contents 1 History 2 Business model 3 Impact 4 See also 5 References 6 External links History BuddyTV was co-founded in 2005 by Andy Liu and David Niu. The pair graduated from the University of Pennsylvania with a Master of Business Administration. They sold their previous company, NetConversions, to aQuantive in 2004...
Read more

Conflict (narrative)

Image
Conflict in narrative comes in many forms. "Man versus man", such as is depicted here in the battle between King Arthur and Mordred, is particularly common in traditional literature, fairy tales and myths. [1] In works of narrative, conflict is the challenge main characters need to solve to achieve their goals. Traditionally, conflict is a major literary element that creates challenges in a story by adding uncertainty to if the goal would be achieved. A narrative is not limited to a single conflict. While conflicts may not always resolve in narrative, the resolution of a conflict creates closure or fulfillment, which may or may not occur at a story's end. Contents 1 Basic nature 2 Classification 2.1 Man against man 2.2 Man against nature 2.3 Man against self 2.4 Man against society 3 History 4 See also 5 References 6 External links Basic nature Conflict in literature refers to the different drives of the characters or forces involved. Conflict may be internal o...
Read more