• Post Reply Bookmark Topic Watch Topic
  • New Topic

Need help to store and print objects in arraylist  RSS feed

 
Daniel Ungerfält
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!
I would like to store some names and id-number in an arraylist<object>.
I have made up the simple person class:


And the main class:


What happens when I try to print it I only got the last name and id * the size of array..
 
Ashwin Rao
Ranch Hand
Posts: 89
C++ Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's what I think: You need to create a new Person object every time you loop through your while() loop in the main function. To that new object you have to set the name and id fields and then add that object to the list. That way you have a list of Person objects for your list.
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dangerous not writing a constructor in that class. If you do that, you will get a default constructor written and that allows you to instantiate the objects in an inconsistent state, with name being null and id being 0.

People tell you that constructors are there to enable objects to be created. But that is only half the story. They are also there to restrict object creation. Giving that object a constructor with name and id means that every time you instantiate that class you must pass name and id. Then you will (probably) have all your objects in a consistent state from the word go.
 
Daniel Ungerfält
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Dangerous not writing a constructor in that class. If you do that, you will get a default constructor written and that allows you to instantiate the objects in an inconsistent state, with name being null and id being 0.

People tell you that constructors are there to enable objects to be created. But that is only half the story. They are also there to restrict object creation. Giving that object a constructor with name and id means that every time you instantiate that class you must pass name and id. Then you will (probably) have all your objects in a consistent state from the word go.



Thanks, I appreciate your help alot. Then I dont need the getters? What´s the getters and setters good for if I can use the construcor the same way?
Well it works now by doing just that,(to use constructor instead of setters n getters) to put differtent values in the same Person p obejct but I dont know exatly why.



>
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You probably need the getXXX methods. You can consider losing the setXXX methods.The above shows your Person class being immutable. You can read about immutability in the Java® Tutorials. The immutable object s a particular design pattern; you can see from the tutorials article what its uses are.


Search for information on the “Bean Pattern”. Beans are different from immutable objects; they must have setXXX and getXXX methods and usually a public no‑arguments constructor. Beans have the advantage that they can be stored in XML files for years and retrieved. They need the setXXX methods with the correct naming conventions to enable the initial values of fields to be set. That appears inconsistent with immutability.

The Color class appears to be immutable (it isn't really because I have managed to break it by some blatant cheating) but if you go through its constructors you find out about an annotation which may allow you to treat an immutable object as a bean. I am not sure about this, since I have never tried, however.
 
Daniel Ungerfält
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:You probably need the getXXX methods. You can consider losing the setXXX methods.The above shows your Person class being immutable. You can read about immutability in the Java® Tutorials. The immutable object s a particular design pattern; you can see from the tutorials article what its uses are.


Search for information on the “Bean Pattern”. Beans are different from immutable objects; they must have setXXX and getXXX methods and usually a public no‑arguments constructor. Beans have the advantage that they can be stored in XML files for years and retrieved. They need the setXXX methods with the correct naming conventions to enable the initial values of fields to be set. That appears inconsistent with immutability.

The Color class appears to be immutable (it isn't really because I have managed to break it by some blatant cheating) but if you go through its constructors you find out about an annotation which may allow you to treat an immutable object as a bean. I am not sure about this, since I have never tried, however.


Oki doki, Thanks for the info.
Took it a bit further:
For some reason I almost never need or uses any arguments for my methods like every videoturtorial or book shows. Its something about that I dont really understand yet.


Im gonna use the main class just to handle a main menu for the different methods.
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, the addPerson method should not be in the Person class. Nor should there be any sign of the List in the Person class.

Single responsibility. The person class takes care of being a person and does not pass any of that responsibility to any other classes or objects. Similarly keeping a List of Persons belongs in a different class.

I know people will disagree but I like structured programming so I try to avoid break; as far as possible.
Challenge: write that loop avoiding break;
Hint: add this statement somewhere in the loop:-
System.out.print("Enter \"stop\" to stop" +
      or anything else to enter more names: ");
 
Daniel Ungerfält
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So you´r saying I should keep all methods that handle such things in my main class?
Then what,except the attributes,constructor and getter/setter methods, should I use the person class, or likewise for?
 
Campbell Ritchie
Marshal
Posts: 56529
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. Not at all. I was saying that there are things which belong to the Person class and things like the List which don't belong to the Person class.
I don't think the belong to a “Main” class. They belong in a different class. I am not sure what I would call it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!