Daniel Greenhouse - Project Portfolio

There are currently eleven main sorting methods present: name, surname, gpa, education, degree, skills, positions, endorsements, skill number, position number, endorsement number. There is also a complimentary reverse sort method for each main sorting method.

(the current list means that if filter is on, only those filtered persons shall be sorted and the filter shall remain on)

Intelligent Sorting:

For a recruiting company with a large number of contacts it is highly likely that certain fields shall be repeated (for example two different persons can both have Bachelors degrees). To aid the user, intelligent sorting has been implemented. It sorts persons that match in the field that the initial sort is looking at and then performs a secondary sort using a method related to the initial sort. The sequences of these are shown below.

The sort command works in a similar fashion to the commands already in place. Below is a sequence diagram for a general sort method. The SortCommandParser implements the already created Parser interface. It is used to take the CLI user input and make a new SortCommand object only if a valid Sort Word has been passed into the CLI.

The SortCommand is an extension of the abstract command class. This means history, command results and addressbook committing follow the same format as the commands in place. This allows it’s compatibility with those commands already present. It takes the list of persons in the addressbook. It ensures that if a filter is present, only these filtered persons are sorted, but the complete persons list is left unaffected. This presents accidental deletion of contact information. The SortCommand class proceeds to take the input, initially from the CLI, and uses processSortMethod to call the necessary sorting method. The sorting method classes all implement the SortMethod interface which executes the necessary sort on the list and has a getList() method.

Once a correctly ordered list of persons has been retrieved by the SortCommand class, it checks for the reverse keyword and makes the necessary adaption. All the persons are then deleted from this model. Due to the severity of this command, additional care has been taken to ensure it can only be processed providing there is a list of persons (of the same length) present to replace it. It then adds the persons back into the addressbook in the correct order, taking note of the filter to ensure compatibility.

Also of note are the methods used in the sorts themselves. Below is shown the sequence diagram for a surname sorting method as an example. The sort methods begin by retrieving the field of interest to the particular sorting method. The aim is to create a Comparator<Person> which can subsequently be easily sorted either numerically or alphabetically. To retrieve the field of interest, the Person class is used. For those fields not suited to numerical or alphabetical sorting, associated values can be generated. For example in the degree field, values are given to the different levels which can then be sorted. These methods should be stored in PersonUtil to keep the frequently used Person class as clear and relevant as possible.

For the skills, positions and endorsements sorting methods, it is required for the person’s individual tags to be sorted first. This uses a sorting method on each person and the creation of new person with correctly ordered skill/position/endorsement tags. Once a comparator has been created, the SortUtil class can be used to perform the actual sorting. This makes use of Java’s stream.Collectors method.

For intelligent sorting the SortListWithDuplicates class is used. It divides the list of persons from the initial sort into smaller lists (dupPersonList) of those returning the same comparator value. These are then individually sorted by the subsequent sorting method. By utilising similar methods for each sort method, this makes the subsequent calling of further sort methods quick and easy. It is worth noting that a subsequent sorting method shall then perform a further sort if its comparator returns a duplicate value within the duplicate list. This process is terminated by the sort name method since the addressbook does not allow people to be added with the same name.

Despite the risk of slightly increasing the coupling, the aim was to use methods already written and rely on good cohesion. For example, once a sort command has correctly written the correctly ordered persons to a List<Person>, rather than duplicating large amounts of code by modifying the already listed persons in the GUI, it shall simply remove the persons in that addressbook version and then immediately re-add them in the correct order.

It is of note that the temporary deletion of persons from the addressbook should be foolproof and there should be no way that the sort command ever permanently deletes the addressbook. Furthermore, ensuring the command works with the already implemented undo/redo command should ensure the user still has full control over all the persons in the contact book.

The future of this product demands the dynamic addition of contact fields as they become important. These fields should then be able to be sorted. Consequently it is paramount that the addition of a further sort command is easy. This is achieved through the SortMethod interface and provision of very adaptable sorting method techniques that can be later used. The steps taken to add a new sort command are provided below.

When writing sort commands, there were two approaches considered: modify the indices of all persons and then refresh the left-hand GUI panel with this new list; or temporarily delete the list of persons and then add a new list of correctly ordered persons.

Elements of lists in Java are ordered by when they were added. Sorting is possible using Collections, however this requires them to be strings. Since the Recruit Me application contains lists of various object types, typically Person, there is no immediate compatibility with Collections. Furthermore it was suspected that to simply modify the indices of persons, a lot of duplicate code would be need to be written since this aspect of addressbook-level4 was not easily modifiable. Because of this the second method was opted for.

It was also decided to make this command as similar as possible in style to those already present. This meant that it was almost immediately compatible with the other commands. This way it could also make use of various methods already in place.

To add a new sort command, the following classes should be altered accordingly:

When choosing the subsequent sort for intelligent sorting, a loop must not be created. For example matching gpa’s can’t use education as a subsequent sorting method if education is already using gpa. This is because if a person has both the same gpa and education, they can’t be sorted.

The developer should also add the necessary testing methods in SortCommandTest and SortCommandIntegrationTest