This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Implementing the Collections interface is one possibility. Perhaps you may want to implement List instead since it provides a more specific contract. Whether or not you implement either of these interfaces, you should add methods that retrieve GDBTrackPoints from the internal ArrayList.
Note that your current implementation of getTrackPoints() is unsafe because the caller can add things to it without the class knowing about it. If you weren't using generics, the caller could add anything to the List, such as Strings, which would be VERY BAD. With generics, the caller is only allowed to add GDBTrackPoint objects, but without GDBTrack knowing there was a change to the underlying list. You may want to return an unmodifiable List. The Collections class has a convenience method to create an unmodifiable List from any List.
I hope this helps answer your question. In the end, implementing Collection (or some other interface) is a design decision. However, it might be helpful to implement some of the same methods that are declared in one of these interfaces.
Extending a concrete class is always risky because the superclass might change in ways that would break your code. Implementing the same interface and delegating the method calls to an instance of the superclass is safer in that respect. You might wind up having to implement a lot of methods, which probably points to some design issues with the original interface but is still a lot of work. Do your clients really have to have the Collection or List interface? If not, you might make your own interface with only the methods you really need and implement the clients to that interface.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Oct 07, 2005
Initially the class was written with just enough methods to do what I needed it to do in my design. This class could be of use to other people so now I'm at the stage of thinking about what the class should really do. A GPS track is really a Collection of trackpoints with some additional variables. Seems like it should be part of the Collections frameework.
Joined: Jan 29, 2003
That's interesting ... your reply here says 2 posts, so I backed up to the top to see if we forgot to welcome a new member on the first post and the original post says 2 posts, too! Somebody at the ranch has trouble counting? Welcome aboard anyhow!
Joined: Dec 06, 2001
Originally posted by Stan James: That's interesting ... your reply here says 2 posts, so I backed up to the top to see if we forgot to welcome a new member on the first post and the original post says 2 posts, too! Somebody at the ranch has trouble counting? Welcome aboard anyhow!
If you look back at your own posts, you will see that they all have the same number, too. Feel free to check any older posts.
I tried implementing the List interface but bogged down in the equals and hashCode methods of the objects to be included in the list. Wasn't making much progress for lots of code changes. I'll keep it in the list of ToDo's for now. I just implemented some of the more useful List methods without the "comparing" ones.
Next step: putting a Swing GUI around the application. I'm getting annoyed entering a long command line already, and I wrote the thing ... >-)