Queues in Java let you delete a random item. This is bad?

Question

Queue Java provides a FIFO data structure. From what I learned, there is a certain responsibility in the lines to adhere to the "first in first" behavior. In other words, you cannot delete items from the middle of the queue. However, in Java, we can remove the elements of a random queue using an iterator .

Is this bad design encapsulation? or should it be a queue data structure?

 Queue<String> queue = new LinkedList<String>(); queue.add("e1"); queue.add("e2"); queue.add("e3"); queue.add("e4"); queue.remove("e3"); 

Answer 1

Queue explicitly inherits some of this added functionality as part of the Collection hierarchy. From a polymorphic point of view, it is useful to have Queue act like any other Collection , as this increases the portability of the data structure.

From a design point of view, I would not say that it is bad. Imagine a line / line at a grocery store. There are situations when a client can be removed from the middle of the line. This particular implementation of the queue supports this, which may be useful.

While you can argue that additional methods will allow you to shoot yourself in the foot, you can easily create a Queue implementation that does not allow things like remove(Object) or iterator.remove() if you want a strict Queue .

Answer 2

In accordance with what I learned, there is a certain responsibility in the queues to adhere to the behavior of "first-in-first".

You probably read a tutorial or lecture notes or something that describes how an idealized FIFO queue works. But you did not understand that not all queues are FIFO. Not in the real world, not in computer systems. (For example, if (presumably) President Obama went to the busy MacDonalds restaurant, you will find that he was immediately moved to the queue before the queue. This queue does not behave in the FIFO.)

In any case, Java Queue is an interface for any queue, not just FIFO queues. It also supports priority queues and any other queue semantics you could dream of ... if you want to provide your own implementation class.

Another point is that the remove(E) operation does not provide the next client operation. This is the equivalent of a customer deciding that they would really prefer pizza ... and going out the door. An idealized queue does not support this, but the library classes used ... because applications should be able to do such things.

The bottom line is that the Java Collection class hierarchy (including the Queue key) is intended for convenience and ease of use, and not for tight fitting some abstract model of data structures.

---

But then Queue can enable the sneakIn method, which allows you to break into the middle of the queue - where is this method?

Well, since most real applications do not need this, it is not there. (If this were a common use case, such a method would be provided in specific queue implementation classes, even if not in the Queue interface.)

Once again, Java classes and interfaces are indicated for their usefulness and usability in real programs, and not (in this case) so that they can simulate POTUS in a twilight hamburger.

Perhaps my brain is washed by descriptions of text books and C / C ++ laboratories that I did at school.

An alternative explanation is that you mistakenly accepted the true purpose of definitions, etc.

Answer 3

Java Queue is not necessarily FIFO. Queue API says

Queues typically, but do not necessarily, order elements in a FIFO (first-in-first-out) manner .

It depends on the implementation, for example PriorityQueue is not a FIFO, but the LinkedList that you used is a FIFO.

The Queue.remove () API does not say that it removes a random element, it says

 Retrieves and removes the head of this queue. 

In your example, this should be

 queue.remove(); 

and he will delete e1