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

Clash 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

asked 3 hours ago

anir

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
  

  
  
  
  

add a comment | 

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

asked 3 hours ago

anir

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
  

  
  
  
  

add a comment | 

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

asked 3 hours ago

anir

24319

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

asked 3 hours ago

anir

24319

share|improve this question

asked 3 hours ago

anir

24319

share|improve this question

share|improve this question

asked 3 hours ago

anir

24319

asked 3 hours ago

anir

24319

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
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  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

add a comment | 

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

edited 1 hour ago

answered 3 hours ago

Andreas

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
  

  
  
  
  

add a comment | 

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

answered 2 hours ago

forpas

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  

  
  
  
  

 | 
show 1 more comment

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

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

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

edited 1 hour ago

answered 3 hours ago

Andreas

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
  

  
  
  
  

add a comment | 

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

edited 1 hour ago

answered 3 hours ago

Andreas

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
  

  
  
  
  

add a comment | 

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

edited 1 hour ago

answered 3 hours ago

Andreas

70.8k453111

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

edited 1 hour ago

answered 3 hours ago

Andreas

70.8k453111

share|improve this answer

share|improve this answer

edited 1 hour ago

edited 1 hour ago

edited 1 hour ago

answered 3 hours ago

Andreas

70.8k453111

answered 3 hours ago

Andreas

70.8k453111

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
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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

add a comment | 

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

answered 2 hours ago

forpas

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  

  
  
  
  

 | 
show 1 more comment

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

answered 2 hours ago

forpas

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  

  
  
  
  

 | 
show 1 more comment

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

answered 2 hours ago

forpas

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.

@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

answered 2 hours ago

forpas

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.

share|improve this answer

share|improve this answer

answered 2 hours ago

forpas

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.

answered 2 hours ago

forpas

5426

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
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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

 | 
show 1 more comment

 

draft saved

draft discarded

 

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

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

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email