Over the course of the last couple weeks, I’ve been messing around with the Java Collections Framework. Specifically, I’ve had to learn a few things about the framework in order to use some of the concrete implementations in a school project. The Java Collections Framework has a lot of moving pieces, and the Oracle tutorials
can be a little confusing. Here is my attempt to demonstrate a simple way to take advantage of the framework.
The Java Collections Framework is a group of interfaces and classes that make it easy to deal with data structures
. A data structure is just a fancy way of referring to structured information. There are many different types of data structures, and an examination of those types is beyond the scope of this post. If you’re interested, here’s one place you can start
. In addition to classically recognized data structures, you’re also free to invent your own type of data structure that is capable of meeting your particular needs in a given project.
Here’s the process I go through when working on a Java project that could benefit from use of the collections framework.
Step 1: Recognize the Need
It’s tough to use a tool if you can’t recognize the situations where it’s needed. In this case, if I find myself storing, accessing, and manipulating a collection
of objects, then this is probably a good time to consider using the collections framework.
Step 2: Choose a Structure
Next, I pick from one of four high-level data structures that are implemented in the Collections Framework: Set, List, Queue, and Map
. If you don’t know what these are, check my earlier link about data structures. However, here’s a very brief description of each.
- Set - A bucket that contains a bunch of unique items.
- List - A bucket that contains a bunch of items. Duplicates are allowed.
- Queue - A bucket that contains a bunch of items that are waiting to do something.
- Map - A bucket that acts like a dictionary. Each item has a key (the dictionary “word”) and a value (the “definition”). Keys have to be unique.
I’ve found that 80% of the problems I’ve encountered can be handled by using some flavor of these four structures.
Step 3: Choose an Implementation
The Java Collections Framework is made up of a bunch of interfaces, abstract classes, and actual implementations of those classes. They are arranged in a hierarchy so that you can use some or all of what’s offered to meet your needs. However, the most straight-forward way to use the framework is to simply use the actual implementations of the classes.
That’s the approach I’ve taken, and it works almost all of the time. It’s an approach that won’t always work, but I prefer to take the simplest, most straight-forward route, and then go back and refactor if I need to make changes.
That being said, here’s how I decide which class implementation to use for each data structure.
Does it need to be ordered? If not, use a HashSet
. Is the order in which they were added to the set sufficient for my ordering needs? If yes, use a LinkedHashSet.
Otherwise, use a TreeSet
Always default to using an ArrayList
. It’s the best for inserting and removing elements at the end of the list. However, if I need to insert or remove elements in the middle of the list, use a LinkedList
Default to using a LinkedList
for any standard type of queue (FIFO, LIFO, etc.). If I need the queue to order its elements in some other way, use a PriorityQueue
Does it need to be ordered? If not, use a HashMap
. Is the order in which they were added to the map sufficient for my ordering needs? If yes, use a LinkedHashMap
. Otherwise, use a TreeMap.
If you choose your collection implementation using the above considerations, you will (usually) end up using the most appropriate and most efficient collection for your needs. There are always exceptions to the rule, but this post was meant to be a high-level look at the framework. I know I didn’t talk about the mechanics of sorting, iterating, or synchronization. Those are discussions for another day.