Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Extend ArrayList?

 
David Wheeler
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a class GDBTrack, that has some class variables and an ArrayList of GDBTrackPoints.

The GDBTrackPoints can be manipulated in all the ways that the contents of an ArrayList would be: add, addAll, remove, clear etc.

Currently I have a getter that returns the ArrayList and lets the calling class use the ArrayList methods to access the GDBTrackPoints.

I'm wondering if I should rewrite GDBTrack to implement the Collections interface or extend ArrayList to have more control over how GDBTrackPoints are added to the GDBTrack.



 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Layne
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
David Wheeler
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Layne
 
David Wheeler
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
New to Java, not new to programming.

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 ... >-)
 
Sonny Gill
Ranch Hand
Posts: 1211
IntelliJ IDE Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David,

If you haven't already read this, Chapter 3 of the book Effective Java (Sample chapters here is the first thing I would recommend that you read when implementing equals, hashCode and Comparable.

HTH.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic