File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes TGIF question: java.util.Deque - really useful or fabulously overengineered? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "TGIF question: java.util.Deque - really useful or fabulously overengineered?" Watch "TGIF question: java.util.Deque - really useful or fabulously overengineered?" New topic
Author

TGIF question: java.util.Deque - really useful or fabulously overengineered?

Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

As you can probably gather, my opinion is the latter; although in my heart I know it should be the first.

27 methods to implement a double-ended queue? (Not to mention the 10 that it inherits from Collection) It's enough to drive an old coder like me to drink...

Not only does it redundantly duplicate all the basic methods of Queue (which probably started the trend) and several of Collection (which it arguably shouldn't extend at all); it offers different versions of them - one that throws Exceptions, and another that doesn't. Has anyone actually used both in the same application?

So now you're stuck with writing at least a few hundred lines of code if you plan on implementing it - even if you extend AbstractQueue.

Opinions anyone? Is this interface extension gone mad?

Next week: java.util.List

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

It could certainly do with some interface segregation.

For instance, Deque supports stack operations. But that should be a separate interface. Unfortunately Stack is already taken because of poor design decisions in Java 1.0. It probably shouldn't extend Queue either, since the equivalent "deque-like" operations actually have different names. (Alternatively, the names should have been chosen so that the same ones could naturally be applied to queues and deques according).

The moral is...don't implement it . Use LinkedList or ArrayDeque, and choose the method names that match the semantic use of what you're doing. So if you want a stack, use push/pop/peek. If you're using a queue, use either add/remove/element or (probably better) offer/poll/peek.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Matthew Brown wrote:For instance, Deque supports stack operations. But that should be a separate interface. Unfortunately Stack is already taken because of poor design decisions in Java 1.0.

Weirdly enough, I love the old Stack API, because (at least at the start) it implemented exactly what I would expect: push(), pop() and peek() (I'm sure you're old enough to remember... ).

I don't even particularly mind it having an add() (as in Collection), remove() (not in any Java Collections Framework class, AFAIK - one might ask: why not?) and peekLast() or tail() methods. But why all these darn variants?

It probably shouldn't extend Queue either, since the equivalent "deque-like" operations actually have different names. (Alternatively, the names should have been chosen so that the same ones could naturally be applied to queues and deques according).

Yah. I think I prefer the 2nd interpretation, because, to me, a Deque is a Queue, and should be substitutable in any situation where you might use one. Queue extends Stack? Not so sure: but it's an interesting discussion.

The moral is...don't implement it . Use LinkedList or ArrayDeque...

Yup, but that means creating new interfaces that should arguably already be in the JCF.

But I take your point. Tilting at windmills again... Hey, it's Friday.

Winston
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

Winston Gutkowski wrote:Weirdly enough, I love the old Stack API, because (at least at the start) it implemented exactly what I would expect: push(), pop() and peek()

I've no problem with the API. But it should have been an interface, not a concrete class. And it extends Vector! They retro-fitted Vector to implement the List interface, but never did the equivalent with Stack (maybe because the obvious interface name was already taken by the class?).
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Matthew Brown wrote:I've no problem with the API. But it should have been an interface, not a concrete class...

Amen.

And it extends Vector!...

Ugh, yes. I'd forgotten about that (drinks beer).

What's the answer? Collections 2: revenge of the Cucooners?

Winston
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4422
    
    8

Winston Gutkowski wrote:
Ugh, yes. I'd forgotten about that (drinks beer).

A bit early for that. But we do have a work party tonight .
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: TGIF question: java.util.Deque - really useful or fabulously overengineered?