Are Java's collections interface and class hierarchy ill done?
Clash Royale CLAN TAG#URR8PPP
up vote
9
down vote
favorite
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 List
and 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 theDeque
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
add a comment |Â
up vote
9
down vote
favorite
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 List
and 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 theDeque
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
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, asLinkedList
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. AQueue
does in fact not have the methods aList
has. But that is why we do not haveQueue implements List
.LinkedList
is both of them, this does not imply that aQueue
now is aList
.
â 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
up vote
9
down vote
favorite
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 List
and 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 theDeque
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
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 List
and 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 theDeque
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
edited 23 mins ago
Peter Mortensen
13.1k1983111
13.1k1983111
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, asLinkedList
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. AQueue
does in fact not have the methods aList
has. But that is why we do not haveQueue implements List
.LinkedList
is both of them, this does not imply that aQueue
now is aList
.
â 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, asLinkedList
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. AQueue
does in fact not have the methods aList
has. But that is why we do not haveQueue implements List
.LinkedList
is both of them, this does not imply that aQueue
now is aList
.
â 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.
It was difficult to swallow: "ALinkedList
is aDeque
. ALinkedList
is aQueue
." (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 findpush()
andpop()
methods inLinkedList
. Now I feelimplements
is 'behaves like' relationship andextends
defines 'is a' relationship. [continued...]
â anir
9 hours ago
[...continued] It seems that the confusion was because I was attachingextends
' 'is a' relationship meaning toimplements
. 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 noStack
interface implemented byLinkedList
as it also havepush()
andpop()
methods. Surely it sounds wrong to dolinkedListObj.push()
. Is this something to do withjava.util.Stack
?
â anir
8 hours ago
@anir Yes, unfortunately they implementedStack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc ofStack
says: "A more complete and consistent set of LIFO stack operations is provided by theDeque
interface and its implementations, which should be used in preference to this class."
â Andreas
4 mins 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.
New contributor
"A queue is a special kind of list" Not always, e.g. aPriorityQueue
is a heap, not a list. --- "List
does not behave" That is about the only thing it does: Behave. TheList
interface is a contract of behavior, e.g. "if you calladd(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 theList
, theList
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
9 hours ago
If my code has aList
, 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. TheList
interface declaration defines a contract, but a list (an object of theList
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 toList
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 theList
interface.
â forpas
8 hours ago
1
"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
8 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.
add a comment |Â
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.
It was difficult to swallow: "ALinkedList
is aDeque
. ALinkedList
is aQueue
." (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 findpush()
andpop()
methods inLinkedList
. Now I feelimplements
is 'behaves like' relationship andextends
defines 'is a' relationship. [continued...]
â anir
9 hours ago
[...continued] It seems that the confusion was because I was attachingextends
' 'is a' relationship meaning toimplements
. 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 noStack
interface implemented byLinkedList
as it also havepush()
andpop()
methods. Surely it sounds wrong to dolinkedListObj.push()
. Is this something to do withjava.util.Stack
?
â anir
8 hours ago
@anir Yes, unfortunately they implementedStack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc ofStack
says: "A more complete and consistent set of LIFO stack operations is provided by theDeque
interface and its implementations, which should be used in preference to this class."
â Andreas
4 mins 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.
It was difficult to swallow: "ALinkedList
is aDeque
. ALinkedList
is aQueue
." (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 findpush()
andpop()
methods inLinkedList
. Now I feelimplements
is 'behaves like' relationship andextends
defines 'is a' relationship. [continued...]
â anir
9 hours ago
[...continued] It seems that the confusion was because I was attachingextends
' 'is a' relationship meaning toimplements
. 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 noStack
interface implemented byLinkedList
as it also havepush()
andpop()
methods. Surely it sounds wrong to dolinkedListObj.push()
. Is this something to do withjava.util.Stack
?
â anir
8 hours ago
@anir Yes, unfortunately they implementedStack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc ofStack
says: "A more complete and consistent set of LIFO stack operations is provided by theDeque
interface and its implementations, which should be used in preference to this class."
â Andreas
4 mins 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.
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.
edited 18 mins ago
Peter Mortensen
13.1k1983111
13.1k1983111
answered 10 hours ago
Andreas
70.8k454111
70.8k454111
It was difficult to swallow: "ALinkedList
is aDeque
. ALinkedList
is aQueue
." (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 findpush()
andpop()
methods inLinkedList
. Now I feelimplements
is 'behaves like' relationship andextends
defines 'is a' relationship. [continued...]
â anir
9 hours ago
[...continued] It seems that the confusion was because I was attachingextends
' 'is a' relationship meaning toimplements
. 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 noStack
interface implemented byLinkedList
as it also havepush()
andpop()
methods. Surely it sounds wrong to dolinkedListObj.push()
. Is this something to do withjava.util.Stack
?
â anir
8 hours ago
@anir Yes, unfortunately they implementedStack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc ofStack
says: "A more complete and consistent set of LIFO stack operations is provided by theDeque
interface and its implementations, which should be used in preference to this class."
â Andreas
4 mins ago
add a comment |Â
It was difficult to swallow: "ALinkedList
is aDeque
. ALinkedList
is aQueue
." (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 findpush()
andpop()
methods inLinkedList
. Now I feelimplements
is 'behaves like' relationship andextends
defines 'is a' relationship. [continued...]
â anir
9 hours ago
[...continued] It seems that the confusion was because I was attachingextends
' 'is a' relationship meaning toimplements
. 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 noStack
interface implemented byLinkedList
as it also havepush()
andpop()
methods. Surely it sounds wrong to dolinkedListObj.push()
. Is this something to do withjava.util.Stack
?
â anir
8 hours ago
@anir Yes, unfortunately they implementedStack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc ofStack
says: "A more complete and consistent set of LIFO stack operations is provided by theDeque
interface and its implementations, which should be used in preference to this class."
â Andreas
4 mins 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
@anir Yes, unfortunately they implemented
Stack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc of Stack
says: "A more complete and consistent set of LIFO stack operations is provided by the Deque
interface and its implementations, which should be used in preference to this class."â Andreas
4 mins ago
@anir Yes, unfortunately they implemented
Stack
as a class, not an interface, way back in the beginning, and we're now stuck with it. As the javadoc of Stack
says: "A more complete and consistent set of LIFO stack operations is provided by the Deque
interface and its implementations, which should be used in preference to this class."â Andreas
4 mins 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.
New contributor
"A queue is a special kind of list" Not always, e.g. aPriorityQueue
is a heap, not a list. --- "List
does not behave" That is about the only thing it does: Behave. TheList
interface is a contract of behavior, e.g. "if you calladd(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 theList
, theList
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
9 hours ago
If my code has aList
, 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. TheList
interface declaration defines a contract, but a list (an object of theList
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 toList
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 theList
interface.
â forpas
8 hours ago
1
"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
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.
New contributor
"A queue is a special kind of list" Not always, e.g. aPriorityQueue
is a heap, not a list. --- "List
does not behave" That is about the only thing it does: Behave. TheList
interface is a contract of behavior, e.g. "if you calladd(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 theList
, theList
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
9 hours ago
If my code has aList
, 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. TheList
interface declaration defines a contract, but a list (an object of theList
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 toList
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 theList
interface.
â forpas
8 hours ago
1
"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
8 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.
New contributor
@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.
New contributor
edited 16 mins ago
Peter Mortensen
13.1k1983111
13.1k1983111
New contributor
answered 10 hours ago
forpas
5528
5528
New contributor
New contributor
"A queue is a special kind of list" Not always, e.g. aPriorityQueue
is a heap, not a list. --- "List
does not behave" That is about the only thing it does: Behave. TheList
interface is a contract of behavior, e.g. "if you calladd(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 theList
, theList
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
9 hours ago
If my code has aList
, 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. TheList
interface declaration defines a contract, but a list (an object of theList
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 toList
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 theList
interface.
â forpas
8 hours ago
1
"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
8 hours ago
add a comment |Â
"A queue is a special kind of list" Not always, e.g. aPriorityQueue
is a heap, not a list. --- "List
does not behave" That is about the only thing it does: Behave. TheList
interface is a contract of behavior, e.g. "if you calladd(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 theList
, theList
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
9 hours ago
If my code has aList
, 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. TheList
interface declaration defines a contract, but a list (an object of theList
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 toList
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 theList
interface.
â forpas
8 hours ago
1
"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
8 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
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
9 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
1
1
"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
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
8 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.
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.
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.
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.
answered 6 hours ago
Federico Peralta Schaffner
20.5k32963
20.5k32963
add a comment |Â
add a comment |Â
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
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
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
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
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
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. AQueue
does in fact not have the methods aList
has. But that is why we do not haveQueue implements List
.LinkedList
is both of them, this does not imply that aQueue
now is aList
.â 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