Kartik,
For some reason I love doing beginners-level homework problems so well that if you (the OP) are silly enough to pass it off as your own work then you'll be caught cheating for sure (unless your teacher is completely incompetent), while still giving you some useful guidance. I guess I'm just another smartass at heart... but a marginally useful one.
Sooo without any further ado...
The Player class: (the one that is/was MIA)
package forums.kartikPatel.tennis;
public class Player {
private final String name;
Player(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
}
This is an immutable data transfer object. "Immutable" is fancy-pants term for "read only". Meaning that once the object has been created (once the Constructor has completed) it cannot be changed. A "data transfer object" is exactly what it's name entails: an object that exists SOLELY to transfer the data that represents something around between other classes which actually "do stuff" with/to that data. It does not (and should not) have any "smarts"... transfer objects should be as simple (as stupid) as possible.
Here's my version of the Team class:
package forums.kartikPatel.tennis;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
public class Team implements Iterable<Player> {
private final String country;
private final List<Player> players;
public Team(String country) {
this.country = country;
this.players = new ArrayList<>();
}
public String getCountry() {
return country;
}
public void addPlayer(Player player) {
players.add(player);
}
public Player getPlayer(int index) {
return players.get(index);
}
@Override
public Iterator<Player> iterator() {
return players.iterator();
}
}
The Team class is another data transfer object. It exists SOLELY to keep all the information that we want to store about a tennis team together in one place. This version works with teams of any number of players, which is good in that we handle teams of three players without changing the software, but in this version it will also accept teams of no players... and I haven't yet seen that in the real world (but hey, if the Kiwis play the team of no-bodies at-least they're in with a even chance, which is a nice change for them), so our software probably shouldn't allow the user to do that, so as a challenge try fixing things (no, the software, not the Kiwis) so that at-least one player is required when populating each team... that or print an "Empty Team!" error message when we come to print-out the line-ups.
I made the Team implement Iterable because it makes sense to view a team as "a bunch of players, from a country" and Iterable allows us to do just that in the Application class, which is coming right up.
The Application class:
package forums.kartikPatel.tennis;
import java.io.PrintStream;
import java.util.Scanner;
public class Application
{
private static final Scanner keyboard = new Scanner(System.in);
private static final PrintStream screen = System.out;
public void run() {
// create two new teams: New Zealand (BOO!) and Australia (YEAH!)
Team[] teams = {new Team("NZ"), new Team("AUS")};
// populate both teams with players
populate(teams);
// display both teams, and all there players.
display(teams);
}
// ------------------------------------------------------------------------
// input
// populate both teams with players
private void populate(Team[] teams) {
for ( Team team : teams ) {
screen.println("Please enter the players for: " + team.getCountry());
for (String name=readPlayersName(); name.length()>0; name=readPlayersName())
team.addPlayer(new Player(name));
screen.println();
}
}
private String readPlayersName() {
return readString("Players Name: ");
}
private String readString(String prompt) {
screen.print(prompt);
return keyboard.nextLine();
}
// ------------------------------------------------------------------------
// output
// display both teams, and all there players.
private void display(Team[] teams) {
screen.println("The line-ups are:");
for ( Team team : teams ) {
System.out.print(team.getCountry() + ": ");
for ( Player player : team )
screen.print(player.getName() + ", ");
screen.println();
}
}
}
As you can see, this is a "traditional" console Application. When you run the tennis.Application it uses a screen and a keyboard to create, populate, and display two teams of players. It contains all the code that actually "does stuff" in this rather simple application. However if/when the two teams get around to actually playing a tennis match I expect we would want a separate class (probably several) to implement playing the game itself... Hell even just keeping the score might involve a Scorer, some Scores, a DueceHelper, and a large box of pine-apples (or possibly NOT).
What the application class does NOT do is "remember stuff"... well not directly. It creates and uses "transfer objects" which "remember stuff".
It's also worth noting that you will see the same three basic steps in all types of applications:
Input,
processing, and
output.
So making these basic steps manifest (ie explicit) in your code is a good idea, especially for a beginner, as it helps you focus on the problem that you need to solve here-and-how... and not get muddled up with the problems that you shouldn't be trying to solve in this method/class/module/subsystem/application... like trying to find a large bread knife to open the box to get the pineapple to beat the ref over the head with during the gentile exchange of opinions over a dodgy line-call ending a tense Love-all in the decider of the third set... Obviously, you should have prepared your ammunition earlier, or just throw the whole frickin box at him and hope his eye-sight improves before the end of the match.
The point is to design each class to fulfill a well-defined set of responsibilities. Each class shall contain methods with simple, understandable names, and indeed each method shall implements a simple, understandable task. This is the essence of good program design. Keeping things as simple-as-possible helps reduce bugs (errors) buy minimising misunderstandings. It also helps make your software flexibly and reusable, which means that it's easier to maintain... to adapt to currently unforseeable future requirements... which all helps reduce the cost of software ownership in the long term, meaning you can charge less than your competitors to do less work which does more good... and that's all good.
And finally my Main class:
package forums;
import forums.kartikPatel.tennis.Application;
public class Main {
public static void main(String[] args) {
new Application().run();
}
}
The Main class has one responsibility: To run the Application.
Doing so produces something like the following output (depending on what you input, obviousy):
Please enter the players for: NZ
Players Name: Bob The Builder
Players Name: Kania Fixit
Players Name: Yazzie Can
Players Name:
Please enter the players for: AUS
Players Name: Mark Horran
Players Name: Blocka Roach
Players Name: The Reverand Fred Effing Nile
Players Name:
The line-ups are:
NZ: Bob The Builder, Kania Fixit, Yazzie Can,
AUS: Mark Horran, Blocka Roach, The Reverand Fred Effing Nile,
As another challenge, try getting-rid of that alloying trailing comma after the last name in each team. Hint: Think "the comma preceeds each subsequent item" instead of the traditional (more obvious) thinking that the comma follows each item except the last one... the trick of course being that it's hard to know when you're dealing with the ultimate item, but you can easily determine if/when you're processing the first (as apposed to subsequent) item of a list.
I hope this helps somewhat. You're doing fine for a beginner. Keep trying and you'll soon understand more than me... it's not hard. I was outsmarted by a fish once... long story ;-)
Cheers. Keith.
