QueueJavaではFIFOデータ構造を提供します。私が学んだことによると、キューには先入れ先出しの動作を順守する責任があります。つまり、キューの途中からアイテムを削除することはできません。ただし、Javaでは、を使用してランダムなキュー要素を削除できますiterator。
これは悪いデザインのカプセル化ですか？または、キューデータ構造はこれを許可することになっていますか？
Queue<String> queue = new LinkedList<String>();
queue.add("e1");
queue.add("e2");
queue.add("e3");
queue.add("e4");
queue.remove("e3");
QueueCollection明らかに、階層の一部になることで、この追加された機能の一部を継承します。ポリモーフィックの観点からは、データ構造の移植性が向上するため、Queue他の方法と同じように動作することが有益です。Collection
デザインの観点からは、必ずしも悪いとは言えません。食料品店の行列/列を想像してみてください。顧客を列の途中から削除する必要がある場合があります。キューのこの特定の実装はそれをサポートしており、これは便利です。
追加のメソッドを使用すると、自分の足を撃つことができると主張することもできますが、厳密なものが必要な場合などQueueを許可しない実装を簡単に作成できます。remove(Object)iterator.remove()Queue
私が学んだことによると、キューには先入れ先出しの動作を順守する責任があります。
あなたはおそらく、理想化されたFIFOキューがどのように機能するかを説明する教科書や講義ノートなどを読んでいるでしょう。しかし、気付いていないのは、すべてのキューがFIFOであるとは限らないということです。現実の世界ではなく、コンピュータシステムでもありません。（たとえば、（仮に）オバマ大統領が忙しいマクドナルドのレストランに行った場合、彼はすぐに列の先頭に移動したことがわかります。これは、FIFO以外の方法で動作する列です。）
とにかく、JavaQueueは、FIFOキューだけでなく、あらゆる種類のキューのインターフェースです。また、優先キューや、独自の実装クラスを提供したい場合に思いつく可能性のあるその他のキューイングセマンティクスもサポートします。
もう一つのポイントは、remove(E)オペレーションが「次の顧客お願い」オペレーションを提供していないということです。これは、顧客が本当にピザを好むと判断し、ドアから出て行くのと同じです。理想化されたキューはこれをサポートしていませんが、使用可能なライブラリクラスはサポートしています...アプリケーションはこの種のことを実行できる必要があるためです。
要するに、JavaCollectionクラス階層（手がかりを含むQueue）は、誰かのデータ構造の抽象モデルに厳密に適合するのではなく、便利で使いやすいように設計されているということです。
しかし、キューはsneakInメソッドを許可する可能性があります。これにより、キューの真ん中に忍び込むことができます。そのメソッドはどこにありますか？
まあ、ほとんどの実際のアプリケーションはそれを必要としないので、それはありません。（それが一般的なユースケースである場合、そのようなメソッドは、インターフェイスにない場合でも、特定のキュー実装クラスで提供されQueueます。）
繰り返しになりますが、Javaクラスとインターフェースは、実際のプログラムでの有用性と使いやすさのために指定されており、（この場合は）ハンバーガージョイントでPOTUSをモデル化できるようには指定されていません。
おそらく私は学校で行った教科書の定義とC/C++ラボに頭を悩ませています。
別の説明は、定義などの真の目的を間違えたということです。
Javaキューは必ずしもFIFOではありません。キューAPIによると
Queues typically, but do not necessarily, order elements in a FIFO (first-in-first-out) manner。
実装によって異なります。たとえば、PriorityQueueはFIFOではありませんが、使用したLinkedListはFIFOです。
Queue.remove（）APIは、ランダムな要素を削除するとは言いません。
Retrieves and removes the head of this queue.
あなたの例では、
queue.remove();
そしてそれは削除されますe1