This particular post is quite code heavy. That said, it’s worth taking the time to review what I’ve found to be an incredibly useful concept which makes life a lot easier when mastered. Onward!
Down Memory Lane…
It’s good practice to revisit old code with the benefit of hindsight. Refactoring code offers us the opportunity to reaffirm what we know know by applying it to what we did then; strengthening our current knowledge by applying it to practical examples we are already familiar with – can our code be made:
- more memory efficient?
- more maintainable?
All points worth considering.
My current project use a lot of generic classes. Like the factory design pattern, generics are one of those things I kinda sorta knew about, but hadn’t really put into practice. In hindsight, it’s a incredibly useful concept that’s had me rushing to refactor the source to my android app with the view to designing a reusable framework to simply and speed up development of further apps… but that’s another story.
In a nutshell, generics allow you to define a reusable class whose properties and method bodies will vary depending on the implementing class. What does that mean though?
A Simple Example
Consider the following unrelated classes, Employee and Stock:
Now we define two classes SpecialEmailList and SpecialStockList. Both have topAndTail method:
And finally our program. Assume we have the following lists:
Given a list of Employee, get first and last. Given a list of Stock, get first and last.
While this approach works, it’s somewhat unwieldy;
- For each new class we want to add to our program, we have to create the corresponding SpecialList class.
- If we want to introduce a new common method, we have to add it to each of our SpecialList classes.
This issue is amplified with each new class we add to the project.
Now for the generic approach. Essentially, all our SpecialList classes do the same thing – hold a list of objects and implement a method that returns first and last object of that list. Consider the following generic class:
Our program changes ever so slightly it’s almost hard to notice (look closely!):
The advantage here is that if we introduce a new class into our program, we can simply implement our SpecialList class without creating any new code, thus making our code more maintainable.
Refactoring Existing Code
Generic classes are a bit like interfaces in that they specify method signatures that must be implemented, but they are also like abstract classes in that we can define method bodies without the class itself having any real context. Like abstract classes, they can be extended.
Since my last post, I have updated my Race Results app twice. The last update involved such a refactoring exercise to make the code easier to maintain. For those of you unfamiliar with my app (download it), here is a sample screen:
Previously, the source to the screen that displays the list of races looked a bit like this:
And that’s just for one screen! I had similar code for the screen that displays drivers, teams, qualifying results, race results…. Maintenance was a real pain. In hindsight, each screen essentially does the same thing:
- take a list of objects.
- display them in some fashion.
- perform some action when item is selected.
Thus I created the following generic class to encapsulate all the common methods:
And thus the code for the screen displaying the list of races is massively simplified, down to 3 methods:
- fetchListItems – obtain list of items to be displayed
- handleItemSelected – define what to do when an item is selected
- populateListItemView – define how item data is to be displayed on screen
As discussed, the code is now much more maintainable, and I was able to easily add a new screen displaying a list of Tweets thus:
Reusability – The Final Touch
The last step for me has been to refactor all my common code into a jar file to be reuable across apps. This will speed up the app development process as a whole, allowing me to put out content much faster. If anyone’s interested, I’ll do a tutorial on that some day 🙂