Printable View
Yes, the problem is with the readFile() method. All the other code works perfectly. I am unsure on how to read data and store the data into variables. I thought the scanner method could achieve that result. I do not understand on how to read each line of code store it into a variable successfully. That is my problem. Can you explain this to me or point me into direction where I can learn.
Again, this method should not be part of the Player class but rather some utility class that has a readPlayer(String name) method, and that returns either a Player object if the file is found or null or throws an exception if no player file is found. What the method should do is read in the data, create a new Player object with the data and the Player constructor, and then return that Player, simple as that. You could use serialization if you so desire to achieve this, or you could use a plain text file if you want the data to be humanly readable (I won't even go into the other options such as database or JAXB right now). The method could even be a static utility method since it really won't have a state.
As for your Scanner object, you seem to be opening and closing the same Scanner variable all over the place. I would simplify this greatly. Just get rid of any class-level Scanner variables, and only create declare a Scanner variable and create its object once at the beginning of a method that needs to use it, and close it at the end of the method. This is part of the KISS philosophy of programming: Keep It Simple Stupid! So in other words, get rid of your Scanner sn variable that you declare at the top of your class and instead create a new variable only inside of methods that need it.
Thank you, Thank you, and Thank you.
You're welcome, and best of luck!Quote:
Originally Posted by loui345
It worked... I had to many scanners opening and not closing.
Wonderful! Glad you've got it solved!
Even though it is solved, do you think i should still rewrite the code and make it like you suggested? It seems like a lot of extra work, but do you think it will pay dividends in the future?
It depends. If this is for a homework assignment, and your work is now complete, then perhaps what you've done is enough, but going forward with new projects I would certainly do this. Again, if I had a Player object it would contain code that allowed me to set and get the "state" of a player, an could have certain player like behaviors, like placeABet() or takeATurn() (if this was a game). I would have a GamePiece classes as needed such as Card and Deck if playing cards, or ChessPiece, ChessBoard, and specific ChessPiece child classes if chess, I would have a Game class that controlled everything. I would have file I/O in a separate class. I would not have any "user interaction" code inside of the core classes such as Player or a game piece class, but rather that would somehow be incorporated in the Game. The idea is to make classes with high "cohesion" -- to have classes where states and behaviors that belong together are in the same class, but with loose "coupling" -- where classes don't handle behaviors that aren't an essential part of it.Quote:
Originally Posted by loui345
Can someone close this it's solved.
There are instructions on closing the thread in the Announcements thread that says Welcome! If it's your first time here, please read.Quote:
Originally Posted by loui345