Forums Register Login

How should I return an array of a class type?

+Pie Number of slices to send: Send
I'm trying to create a method 'GetPlayers' that returns an array of Class 'Player' inside the Class itself - Good idea or bad idea?

If good, how would I use the method to create an instance of the array?

e.g.
Player players = new Player.GetPlayers();
(yes it's still early days for me :rolleyes

Many thanks

Paul.



public class Player {
private int gold = 30;
private int warriors = 10;
private int food = 25;

private int[] boughtItems = null;
private int[] foundItems = null;

private int kingdom = 0;
private int moves = 0;
private int lastLocation = 0;
private boolean cursed = false;

public Player[] GetPlayers(){
Player players[];
players = new Player[6]; //CurrPlayer, 4xPlayers + Dragon

for (int i=0; i<players.length; ++i)
players[i] = new Player();
players[5].gold = 0; //Dragon!!!
players[5].warriors = 0; //Dragon!!!

return players;
}
}
+Pie Number of slices to send: Send
+Pie Number of slices to send: Send
to expand on Tim's comment, after you create the players array, you need to put some players IN the arrray (assuming you want some in there. you'd need something like

players[0] = new Player();
players[1] = new Player();
etc.

this could be done with a loop as well. the point is that the line

Player[] players = new Player[5];

creates an empty array that can hold up to 5 players. you need to populate the array however works for you.
+Pie Number of slices to send: Send
Hi Paul,
your method is ok, only looks a bit weird due to missing indentation.

But your call is wrong, should be like




Yours,
Bu.
+Pie Number of slices to send: Send
I would expect a getPlayers method to simply return a reference to a private field (an array of Players that's being maintained in that instance) and not actually "do" anything to the Players in that array...

Separate methods might initialize (reset) or modify this array...

Does that make sense?
+Pie Number of slices to send: Send
 

I would expect a getPlayers method to simply return a reference to a private field (an array of Players that's being maintained in that instance) and not actually "do" anything to the Players in that array...

Separate methods might initialize (reset) or modify this array...



I see what you're saying.

Would these manipulating methods be okay defined in the Player class?
+Pie Number of slices to send: Send
well, that's how you access private data in a class,
you just create a public function/method to modify, return,
or update that piece of private data..

now say you have a private static player[], and it's member data.

then you could make a public static Player[] getPlayers(){}

method, that stores the current Player[] in your private class
into a new array in the client.

ex:
Player [] a = Player.getPlayers();


If I am wrong, or off track, please let me know

Justin


LOL just ignore this post...
[ October 12, 2006: Message edited by: Justin Fox ]
+Pie Number of slices to send: Send
 

Originally posted by Paul Carter:


I see what you're saying.

Would these manipulating methods be okay defined in the Player class?



If the class is Player and not plural, I would expect all non-static methods to return only data about itself, a single player. If you need to have a group of players, it should be done outside that class.

Would you expect a JButton object to return all JButton objects in a GUI? Or a single Integer object to return all Integers that have been created?
[ October 12, 2006: Message edited by: Rusty Shackleford ]
Without subsidies, chem-ag food costs four times more than organic. Or this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 994 times.
Similar Threads
ObjectStream client-server object sharing problem.
Incompatibe Types & Symbol Not Found
Spring MVC JDBC
Why am I getting NullPointerException?
Referencing an array via a method.
More...

All times above are in ranch (not your local) time.
The current ranch time is
Apr 16, 2024 04:27:20.