In this section we upgrade the code to use generics

Why?

The original code doesn’t deal with using other collection types very well, basically you would have to copy the code and change it.

The tests are written, so we now move into a TDD way coding, don’t break the existing tests

I’ve circled in red all the areas I want to address.

Line No	Issue	Proposed Solution
20	TextFileSource - needs the declared as a generic	TextFileSource<T>
20	IDataSource - needs to be a generic	IDataSource<T>
22	Returning a, Iterable<String> is constraining. There are other collection types in the JDK that do not decend from Collection and do not implement the Iterable interface	Return the datatype that actually holds the data
24	The solution is too restrictive, binding the functor to an ArrayList<String>	I would like to tie the ICollectionLoader to the generic parameter type that will be passed into TextFileSouce
32	Same as line 22	Return the datatype that actually holds the data
32	ICollectionLoader should be bound to the generic type passed into TextFileSource	ICollectionLoader<T>
34	This is crazy, it’s such tightly coupled code to ArrayList<String>	The object should be passed in, so the method signature should look like this `public T loadData( String fname, T lines, ICollectionLoader<T> func )` The idea being that `func` will know how to operate on the collection `lines` that is being passed. So this will allow us to provide any collection type and a custom function to manipulate the items being added to the collection

The road to Generics

Start by checking out to git tag v1.5-tests_completed_code_refactored with the command git tag v1.5-tests_completed_code_refactored
We’ll begin by modifying the TextFileSource, replacing references of Iterable<String> with ArrayList<String>
Once completed make sure the tests still pass - test_count_chars_in_BasicDataProcessor_no_mocking
So your code should look like this
You should that you are getting errors in App and TextFileSource if you’ve started from the git tag v1.5-tests_completed_code_refactored. We need to fix the method loadData() in IDataSource so it now matches the revised method id TextFileSource, so it should look like this now
1. ```
public interface IDataSource
{
    public  ArrayList<String>  loadData(  String fname );
    public  ArrayList<String>  loadData(  String fname, ArrayList<String> storage, ICollectionLoader func );
}
```
2. Notice that we’ve updated the return type of each method so they match the methods in TextFileSource
And App should now look like this
We now need to templatize the class, methods, and parameters so the type is consistent across all three points
You will get an error because the interface is out of sync with what we what the implementation class to look like, so update IDataSource to to following

public interface IDataSource<T>
{
    public  <T> T  loadData(  String fname );
    public  <T> T  loadData(  String fname, T storage, ICollectionLoader func );
}

But will still be getting an error in TextFileSource
It is to do with the functor. ICollectionLoader is a Generic and it’s bound to ArrayList<String>, if we don’t specify a generic parameter type for ICollectionLoader, the Java compiler widens it to Object. Also in the line where we create the functor, we cannout use the generic param T because the Java compiler is unable to determine if the c.add() is a method on the type T. So in both cases we need to help the compiler. We need to update IDataSource again to the following
1. ```
public interface IDataSource<T>
{
    public  <T> T  loadData(  String fname );
    public  <T> T  loadData(  String fname, T storage, ICollectionLoader<T> func );
}
```
We are not telling ICollectionLoader to expect a type T not a type Object
Update TextFileSource as shown here
In both cases we are helping the Java compiler
Now complete the process by update the App class

Advanced Upgrade

The road to Generics