Need help to store and print objects in arraylist

[Daniel Ungerfält]

Hi!
I would like to store some names and id-number in an arraylist<object>.
I have made up the simple person class:

public class Person {
	private String name;
	private String id;
	
	

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getId() {
		return id;
	}

	public void setId(String id) {
		this.id = id;
	}
	
	
}

And the main class:

import java.util.ArrayList;
import java.util.Scanner;


public class Register {

	public static void main(String[] args) {
		
		Scanner sc = new Scanner(System.in);
		
		Person p = new Person();
		

		ArrayList<Person> list = new ArrayList<Person>();
		
		String s = "";
		
		int n= 0;
		
		while(!s.equals("q")){
		
		System.out.println("Input name and id");
		
		s = sc.nextLine();
		
		String id = sc.nextLine();
		
		p.setName(s);
		p.setId(id);
		list.add(n,p);
		n = n +1;
		}
		
		for(int i = 0; i<list.size(); i++){
		System.out.println(list.get(i).getName() +" "+ list.get(i).getId());
		}
		
	}

}

What happens when I try to print it I only got the last name and id * the size of array..

[Ashwin Rao]

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]

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]

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.

ArrayList<Person> list = new ArrayList<Person>();
		
		String s = "";
		
		int n= 0;
		
		while(true){
		
		System.out.println("Input name and id");
		
		s = sc.nextLine();
		
		if(s.equals("q"))
			break;
		
		String id = sc.nextLine();
		
		Person p = new Person(s,id);
	
		list.add(n,p);
		n = n +1;
		}
		
		for(int i = 0; i<list.size(); i++){
		System.out.println(list.get(i).getName() +" "+ list.get(i).getId());
		}
		
	}

}

>

[Campbell Ritchie]

You probably need the getXXX methods. You can consider losing the setXXX methods.

public final class Person
{
   private final int id;
   private final String name;

   public Person (String name, int id)
   {
      this.name = name;
      this.id = id;
   }

   // getXXX equals hashCode and toString 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]

Campbell Ritchie wrote:You probably need the getXXX methods. You can consider losing the setXXX methods.

public final class Person
{
   private final int id;
   private final String name;

   public Person (String name, int id)
   {
      this.name = name;
      this.id = id;
   }

   // getXXX equals hashCode and toString 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.

import java.util.ArrayList;
import java.util.Scanner;

public class Person {
	private String name;
	private String id;
	private ArrayList<Person> list = new ArrayList<Person>();

	Scanner sc = new Scanner(System.in);

	public Person(String name, String id) {
		super();
		this.name = name;
		this.id = id;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	public String getId() {
		return id;
	}

	public void setId(String id) {
		this.id = id;
	}

	public void addPerson() {
		String s = "";
		int n = 0;
		while (true) {
			System.out.println("Input name and id");
			s = sc.nextLine();
			if (s.equals("q"))
				break;
			String id = sc.nextLine();
			Person p = new Person(s, id);
			list.add(n, p);
			n = n + 1;
		}
	}

	public void getPerson() {
		System.out.println("Input Id: ");
		String id = sc.nextLine();
		for (int i = 0; i < list.size(); i++) {
			if (id.equals(list.get(i).getId()))
				System.out.println("This ID belongs to: "
						+ list.get(i).getName());
		}

	}
}

Im gonna use the main class just to handle a main menu for the different methods.

[Campbell Ritchie]

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]

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]

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.