Why are AbstractQueue and AbstractList disjointed?
During my C learning days, when I had implemented a Queue
, I implemented them on top of a LinkedList
. So essentially I had two pointers (front and rear) for the Queue
operations on top of LinkedList
, or开发者_开发知识库 better one front pointer on top of a CircularLinkedList
.
I am learning the Java Collections Framework
, and I observe that the design has completely disjointed the List
and Queue
interfaces, and the implementations branches out in following fashion -
I think AbstractQueue
should have been subclassed somewhere inside AbstractList
. Maybe not inside ArrayList
, because I do not want random access to elements, but maybe inside AbstractSequentialList
, hmm? (I realize, I could be completely wrong here)
This sounds like something done for implementation flexibility: a queue doesn't have to be implemented as a list (in particular a priority-queue is almost certainly a heap underneath, which is a much more random-access structure than a list can offer).
I think the interfaces should be disjoint, but there is a link in the method of implementation as you have identified. A list and a queue are conceptually different to the consumer when treated as a black box, even if there is a link between how you might implement them using a linked list.
Doesn't the Liskov Substitution Principle come into play here? An AbstractQueue IS NOT an AbstractList, so it shouldn't inherit from it. It's implementation may use one, however, but by composition not inheritance.
精彩评论