• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Removing an ArrayList element

 
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The purpose of the following code is to remove an element (contact from a list of contacts). What I have noticed is that I can remove a contact by object as well as by index. IntelliJ suggests that for a boolean return use the object to remove the element, and for a Contact return use the index of the item. So in this case, would it be more appropriate to use the object to remove the element as IntelliJ suggests?


 
Bartender
Posts: 7429
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It could have been achieved  more simply as
Also, please don't use "this." when it's not necessary.
 
bryant rob
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I definitely agree with your simpler return but I'm working on getting to that point. At this point I still need to be able to see the code with the if/else to understand it in my head.  If I would have stated remove(foundContact) which removes the contact at the specified index position would this have been considered acceptable since it would provide the same result?

Also, if the constructor intializes the this.myContact equal to the ArrayList,  how do I know when to use "this" or not? I'm just following the constructor.  
 
Carey Brown
Bartender
Posts: 7429
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

You could have written it this way but you might be asking List to potentially look for the contact in the List twice, once by using equals() and once by using index. This would be dependent upon which type of List you instantiated. My simplified version would only look once in all cases. Also, you had to do the extra step of returning your own boolean because the return type of remove(index) is an object, not a boolean.

Regarding "this.", it is used to disambiguate code where there is both a local variable and a class variable of exactly the same name. The compiler would assume you meant the local variable unless you prefix it with "this.".
 
bryant rob
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Carey Brown wrote:You could have written it this way but you might be asking List to potentially look for the contact in the List twice, once by using equals() and once by using index.


You are correct, which is why I created another findContact method and overloaded it.



Carey Brown wrote:This would be dependent upon which type of List you instantiated. My simplified version would only look once in all cases. Also, you had to do the extra step of returning your own boolean because the return type of remove(index) is an object, not a boolean.

Regarding "this.", it is used to disambiguate code where there is both a local variable and a class variable of exactly the same name. The compiler would assume you meant the local variable unless you prefix it with "this.".


Thanks, I understand what you are stating.
 
Carey Brown
Bartender
Posts: 7429
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:

Carey Brown wrote:You could have written it this way but you might be asking List to potentially look for the contact in the List twice, once by using equals() and once by using index.


You are correct, which is why I created another findContact method and overloaded it.


This will probably be worse than the findContact() method in your first post. What if the List is  a TreeList? The above method would have to visit each node in order whereas remove(contact) could use the indexing ability of the TreeList and reduce that significantly. Even if it was an ArrayList you'd still have to find the contact object to get the index, and then as a second step, use the index to remove the contact.  Potentially double work. For ArrayList it might not be too bad but if it was a LinkedList then getting to an index could be expensive.
 
Marshal
Posts: 71025
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another problem about that approach is that it doesn't follow the conventions of object orientation. That method to find an index does work which would be better done inside the list object. For a linked list, that loop will run in O(n²) time complexity.
 
bryant rob
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Carey Brown wrote:What if the List is  a TreeList? The above method would have to visit each node in order whereas remove(contact) could use the indexing ability of the TreeList and reduce that significantly. Even if it was an ArrayList you'd still have to find the contact object to get the index, and then as a second step, use the index to remove the contact.  Potentially double work. For ArrayList it might not be too bad but if it was a LinkedList then getting to an index could be expensive.



I can see your point with regard to the double work, but I haven't gotten to linkedLists in my studies yet. In the Arrays section the content order is as follows:

Array
ArrayLists
Autoboxing and Unboxing
Linked Lists

In the Array and ArrayList section as you can see I am working with a phone contact list. Pretty basic to I'm sure most on the forum, but it gives me a clear visual as to how the inner workings of something so basic works using java. Next up is the Autoboxing and Unboxing then linked lists...cant' wait.  
I absolutely am loving this section and can't wait to finish it. The next section is Inner and Abstract classes  and Generics. The course does seem to get more interesting as it goes on and at least I can see more of a real world application for java which is pretty cool.
 
Saloon Keeper
Posts: 12488
269
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Carey's remark boils down to this guideline: You should never use get() inside of a loop. If you want to iterate over elements of a collection, use an enhanced for-loop:

If you want to modify a collection while you're iterating over it, use an iterator:
 
Campbell Ritchie
Marshal
Posts: 71025
291
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can use get() at any time for a random access list, and the standard API marks a few kinds of List as RandomAccess. That means lists backed by an array. But get() doesn't work at all well for a linked list; it gives slow performance. You can even write
 
Stephan van Hulst
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should not assume that a collection is random access, unless your algorithm absolutely depends on it, and in that case you should require that the parameter or field is of the required type. You can do that with type bounds:

However, in the vast majority of cases there simply is no need to perform random access more than once, and even then the exceptions can usually be handled by using an iterator instead.
 
bryant rob
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After reading Oracle's tutorial and learning that the enhanced version of the for loop is the form designed for iteration through Collections and arrays, why would the way I used the get.Name not be recommended or accepted as proper code form when Oracle states " We recommend using this form of the for statement instead of the general form whenever possible"  when the way I used it in the general form of the for loop is clearly easy for anyone to read and understand the purpose of the code, and it gets the job done? I am not trying to be a rebel here, just understand why I should not do it. Is it less efficient?

 
Carey Brown
Bartender
Posts: 7429
66
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

bryant rob wrote:After reading Oracle's tutorial and learning that the enhanced version of the for loop is the form designed for iteration through Collections and arrays, why would the way I used the get.Name not be recommended or accepted as proper code form when Oracle states " We recommend using this form of the for statement instead of the general form whenever possible"  when the way I used it in the general form of the for loop is clearly easy for anyone to read and understand the purpose of the code, and it gets the job done? I am not trying to be a rebel here, just understand why I should not do it. Is it less efficient?


For a LinkedList, to find a match in the 5th node your loop would need to search on the first iteration:
Nodes: 0
On the 2nd iteration
Nodes: 0, 1
On the 3rd iteration
Nodes: 0, 1, 2
On the 4th iteration
Nodes:  0, 1, 2, 3
On the 5th iteration
Nodes: 0, 1, 2, 3, 4

As you can see, each iteration causes get() to internally start over at 0. It doesn't simply go to the next entry. Using an iterator or an enhanced for-loop fixes this issue.
 
Stephan van Hulst
Saloon Keeper
Posts: 12488
269
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Compare it to delivering a newspaper in a street. The general form is like putting your cart with papers at the start of the street, and then walking up to each door delivering one newspaper and then walking back to the cart to get the next newspaper. The enhanced for-loop is like taking the cart of papers with you from door to door.
 
Campbell Ritchie
Marshal
Posts: 71025
291
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Compare it to delivering a newspaper in a street. . . . .

That's the best explanation I have seen for a long time of why to avoid get() on linked lists. For lined lists, always use the Iterator. By the time you get to this section, which I presume is the Java™ Tutorials section you meant, BR, you haven't heard of Iterators yet, so they keep quiet about the enhanced for loop using Iterators in the background.
 
bryant rob
Rancher
Posts: 115
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Carey and Stephan for the explanations. It definitely makes sense and peaked my interest to learn more on iterators and get.

Campbell, you are correct as you always are.  I haven't made it to iterators yet. What I usually do while going through this Udemy course is when I get to a new section, like I am on Arrays and ArrayLists I will read the Oracle tutorials on the topic and this is where I usually write notes (on my paper . I saw where the enhanced for loop was preferred but I just figure that eventually the course will get to that specific topic (which normally it does cover what is mentioned in the tutorial), and if it doesn't I have it written in my notes and will go back at some time in the future and research it.  
 
Grow your own food... or this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic