You can even get rid of the if statement:
Gary Doyle wrote:Does anyone know you can change this code so that when a lot is removed it wont move up in the index. e.g if you removed lot 2, lot 3 would move into lot 2.
So some smells here:
1. Why use a List if the lot's number field has to be in synch with its relative position? you should use a fixed structure, like a Lot (an array) then.
2. If you want a Lot's relative position to be fixed, what's the point of having a lot.number field then?
The cognitive dissonance in these design choices is what is making it difficult for you to understand how to write your code.
If, indeed, the lot's relative position within a collection is not really important after all, then you can use a Map as suggested. The other option is to use the Stream API as I showed.
Gary Doyle wrote:it is code giving to us from the lecturer, he asked us to change it so that it wouldn't move up the index as a excercise. None of this is my code and from what I've found myself is that it is easier to delete all the code and start again like you have. Thanks for your help
If you don't want to have it move up an index, then instead of deleting it replace it with null using:
add(int index, E element)
This will, of course, result in more and more null entries over time and is not an ideal choice, but it works.
Gary Doyle wrote:it is code giving to us from the lecturer
Hmm. Well, since it is for a class then I really shouldn't have given a full solution like that. Cat's out of the bag now though. I guess since the solution given doesn't meet the requirements, no harm no foul then. At any rate, you should consider Carey's suggestion and go through the JavaDocs for List and see if you can find an appropriate method that you can call to effectively delete an item from the list without actually removing an item and shifting everything around. You should be able to find something that fits the bill.