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

Clash Royale CLAN TAG#URR8PPP

up vote
9
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 is stuff that lists can do, but queues can't. But the list can behave like a queue. For example, List interface has the following methods:

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

But Queue has only the following:

add(E e)

So clearly Queue is not allowed to insert at specific index, which is allowed in List. The 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 a more generalized data structure and can emulate Queue.

Now being capable to emulate is different from having a contract subset. That is, Queue disallows certain operations (indexing) of Listand allows certain operations done only in a particular manner (insert only at the tail and remove only from the 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 it's 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 don't get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of a queue does not allow insertion at an 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 it's 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

edited 11 mins ago

Peter Mortensen

13.1k1983111

asked 10 hours ago

anir

25819

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  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
  10 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
  10 hours ago
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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
  10 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

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

  
  
  
  

add a comment | 

up vote
9
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 is stuff that lists can do, but queues can't. But the list can behave like a queue. For example, List interface has the following methods:

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

But Queue has only the following:

add(E e)

So clearly Queue is not allowed to insert at specific index, which is allowed in List. The 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 a more generalized data structure and can emulate Queue.

Now being capable to emulate is different from having a contract subset. That is, Queue disallows certain operations (indexing) of Listand allows certain operations done only in a particular manner (insert only at the tail and remove only from the 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 it's 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 don't get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of a queue does not allow insertion at an 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 it's 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

edited 11 mins ago

Peter Mortensen

13.1k1983111

asked 10 hours ago

anir

25819

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  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
  10 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
  10 hours ago
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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
  10 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

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

  
  
  
  

add a comment | 

up vote
9
down vote

favorite

1

up vote
9
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 is stuff that lists can do, but queues can't. But the list can behave like a queue. For example, List interface has the following methods:

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

But Queue has only the following:

add(E e)

So clearly Queue is not allowed to insert at specific index, which is allowed in List. The 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 a more generalized data structure and can emulate Queue.

Now being capable to emulate is different from having a contract subset. That is, Queue disallows certain operations (indexing) of Listand allows certain operations done only in a particular manner (insert only at the tail and remove only from the 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 it's 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 don't get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of a queue does not allow insertion at an 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 it's 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

edited 11 mins ago

Peter Mortensen

13.1k1983111

asked 10 hours ago

anir

25819

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 is stuff that lists can do, but queues can't. But the list can behave like a queue. For example, List interface has the following methods:

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

But Queue has only the following:

add(E e)

So clearly Queue is not allowed to insert at specific index, which is allowed in List. The 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 a more generalized data structure and can emulate Queue.

Now being capable to emulate is different from having a contract subset. That is, Queue disallows certain operations (indexing) of Listand allows certain operations done only in a particular manner (insert only at the tail and remove only from the 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 it's 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 don't get how we can say "LinkedList implementation happens to satisfy the Deque contract". The concept of a queue does not allow insertion at an 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 it's 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

edited 11 mins ago

Peter Mortensen

13.1k1983111

asked 10 hours ago

anir

25819

share|improve this question

edited 11 mins ago

Peter Mortensen

13.1k1983111

asked 10 hours ago

anir

25819

share|improve this question

share|improve this question

edited 11 mins ago

Peter Mortensen

13.1k1983111

edited 11 mins ago

Peter Mortensen

13.1k1983111

edited 11 mins ago

Peter Mortensen

13.1k1983111

13.1k1983111

asked 10 hours ago

anir

25819

asked 10 hours ago

anir

25819

asked 10 hours ago

anir

25819

25819

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  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
  10 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
  10 hours ago
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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
  10 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

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

  
  
  
  

add a comment | 

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  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
  10 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
  10 hours ago
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  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
  10 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

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

  
  
  
  

10

10

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
10 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
10 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
10 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
10 hours ago

3

3

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
10 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
10 hours ago

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

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

add a comment | 

3 Answers
3

active

oldest

votes

up vote
25
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 it shrinks when queue is emptied.




• ArrayDeque uses less memory, but it 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 a 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 7 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  9 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
  9 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
  – Andreas
  9 hours 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
  8 hours ago
  

  
  
  
  

add a comment | 

up vote
3
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 is stuff that lists can do, but queues can't.

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

forpas

5528

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  "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
  9 hours 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
  8 hours 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
  8 hours 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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  "In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
  – Stephen C
  7 hours ago
  

  
  
  
  

add a comment | 

up vote
1
down vote

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.

LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.

So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.

For example, look at the following interfaces:

public interface BloodDrinker 

 void drinkBlood();


public interface FlyingInsect 

 void flyAround();

The above interfaces clearly define behavior. Each one of them has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operations defines what it must do, but not how.

Now consider the Mosquito class:

public class Mosquito implements FlyingInsect, BloodDrinker 

 public void flyAround() 
 // fly by moving wings
 

 public void drinkBlood() 
 // drink blood by biting other animals:
 // suck their blood and inject saliva
 

Now, this means that a mosquito is both a flying insect and a blood drinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

add a 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%2fare-javas-collections-interface-and-class-hierarchy-ill-done%23new-answer', 'question_page');

);

Post as a guest

Name Email

3 Answers
3

active

oldest

votes

3 Answers
3

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
25
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 it shrinks when queue is emptied.




• ArrayDeque uses less memory, but it 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 a 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 7 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  9 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
  9 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
  – Andreas
  9 hours 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
  8 hours ago
  

  
  
  
  

add a comment | 

up vote
25
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 it shrinks when queue is emptied.




• ArrayDeque uses less memory, but it 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 a 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 7 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  9 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
  9 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
  – Andreas
  9 hours 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
  8 hours ago
  

  
  
  
  

add a comment | 

up vote
25
down vote

up vote
25
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 it shrinks when queue is emptied.




• ArrayDeque uses less memory, but it 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 a 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 7 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

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 it shrinks when queue is emptied.




• ArrayDeque uses less memory, but it 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 a 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 7 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

share|improve this answer

share|improve this answer

edited 7 mins ago

Peter Mortensen

13.1k1983111

edited 7 mins ago

Peter Mortensen

13.1k1983111

edited 7 mins ago

Peter Mortensen

13.1k1983111

13.1k1983111

answered 10 hours ago

Andreas

70.8k454111

answered 10 hours ago

Andreas

70.8k454111

answered 10 hours ago

Andreas

70.8k454111

70.8k454111

• 
  
  
  

  
  

  
  
  
  
  
  

  
  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
  9 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
  9 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
  – Andreas
  9 hours 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
  8 hours 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
  9 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
  9 hours ago
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
  – Andreas
  9 hours 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
  8 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
9 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
9 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
9 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
9 hours ago

3

3

@anir Sorry, you're right. implements is behaves like. The important part to remember is that behaves like is a one-way relationship.
– Andreas
9 hours 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
9 hours 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
8 hours 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
8 hours ago

add a comment | 

up vote
3
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 is stuff that lists can do, but queues can't.

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

forpas

5528

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  "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
  9 hours 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
  8 hours 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
  8 hours 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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  "In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
  – Stephen C
  7 hours ago
  

  
  
  
  

add a comment | 

up vote
3
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 is stuff that lists can do, but queues can't.

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

forpas

5528

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  "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
  9 hours 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
  8 hours 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
  8 hours 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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  "In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
  – Stephen C
  7 hours ago
  

  
  
  
  

add a comment | 

up vote
3
down vote

up vote
3
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 is stuff that lists can do, but queues can't.

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

forpas

5528

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 is stuff that lists can do, but queues can't.

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

answered 10 hours ago

forpas

5528

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

edited 4 mins ago

Peter Mortensen

13.1k1983111

edited 4 mins ago

Peter Mortensen

13.1k1983111

edited 4 mins ago

Peter Mortensen

13.1k1983111

13.1k1983111

answered 10 hours ago

forpas

5528

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 10 hours ago

forpas

5528

answered 10 hours ago

forpas

5528

5528

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.

• 
  
  
  

  
  

  
  
  
  
  
  

  
  "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
  9 hours 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
  8 hours 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
  8 hours 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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  "In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
  – Stephen C
  7 hours ago
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  "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
  9 hours 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
  8 hours 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
  8 hours 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
  8 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  "In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
  – Stephen C
  7 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
9 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
9 hours 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
8 hours 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
8 hours 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
8 hours 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
8 hours 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
8 hours 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
8 hours ago

"In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
– Stephen C
7 hours ago

"In computer science syllabus, I was never taught that queue can be a list or more precisely queue can behave like a list ..." There are lots of things that are not explicitly spelled out in a University level course. Rather students are expected to develop the understanding and the mental skills to work these things out for themselves.
– Stephen C
7 hours ago

add a comment | 

up vote
1
down vote

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.

LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.

So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.

For example, look at the following interfaces:

public interface BloodDrinker 

 void drinkBlood();


public interface FlyingInsect 

 void flyAround();

The above interfaces clearly define behavior. Each one of them has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operations defines what it must do, but not how.

Now consider the Mosquito class:

public class Mosquito implements FlyingInsect, BloodDrinker 

 public void flyAround() 
 // fly by moving wings
 

 public void drinkBlood() 
 // drink blood by biting other animals:
 // suck their blood and inject saliva
 

Now, this means that a mosquito is both a flying insect and a blood drinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

add a comment | 

up vote
1
down vote

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.

LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.

So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.

For example, look at the following interfaces:

public interface BloodDrinker 

 void drinkBlood();


public interface FlyingInsect 

 void flyAround();

The above interfaces clearly define behavior. Each one of them has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operations defines what it must do, but not how.

Now consider the Mosquito class:

public class Mosquito implements FlyingInsect, BloodDrinker 

 public void flyAround() 
 // fly by moving wings
 

 public void drinkBlood() 
 // drink blood by biting other animals:
 // suck their blood and inject saliva
 

Now, this means that a mosquito is both a flying insect and a blood drinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

add a comment | 

up vote
1
down vote

up vote
1
down vote

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.

LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.

So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.

For example, look at the following interfaces:

public interface BloodDrinker 

 void drinkBlood();


public interface FlyingInsect 

 void flyAround();

The above interfaces clearly define behavior. Each one of them has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operations defines what it must do, but not how.

Now consider the Mosquito class:

public class Mosquito implements FlyingInsect, BloodDrinker 

 public void flyAround() 
 // fly by moving wings
 

 public void drinkBlood() 
 // drink blood by biting other animals:
 // suck their blood and inject saliva
 

Now, this means that a mosquito is both a flying insect and a blood drinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

LinkedList is a class that implements both List and Deque interfaces. Each one of these interfaces defines a contract with operations, and in these contracts it is specified what these operations must do. However, it is not specified how these operations are supposed to work.

LinkedList is a class that implements both List and Deque interfaces. So, despite the suffix List is part of the name of the LinkedList class, LinkedList is actually both a List and a Deque, because it implements all of the operations that are defined in the List and Deque interfaces.

So LinkedList is a a List, and it also is a Deque. This doesn't mean that a List should be a Deque, or that a Deque should be a List.

For example, look at the following interfaces:

public interface BloodDrinker 

 void drinkBlood();


public interface FlyingInsect 

 void flyAround();

The above interfaces clearly define behavior. Each one of them has a single operation and defines a contract. The drinkBlood operation defines what a BloodDrinker must do, but not how. Same applies for a FlyingInsect: its flyAround operations defines what it must do, but not how.

Now consider the Mosquito class:

public class Mosquito implements FlyingInsect, BloodDrinker 

 public void flyAround() 
 // fly by moving wings
 

 public void drinkBlood() 
 // drink blood by biting other animals:
 // suck their blood and inject saliva
 

Now, this means that a mosquito is both a flying insect and a blood drinker, but why would a blood drinker necessarily be a flying insect, or a flying insect necessarily be a blood drinker? For example, vampires are blood drinkers, but not flying insects, while butterflies are flying insects, but not blood drinkers.

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

share|improve this answer

share|improve this answer

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

answered 6 hours ago

Federico Peralta Schaffner

20.5k32963

20.5k32963

add a comment | 

add a 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%2fare-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