After much tutorial-watching and book reading I've come to realize that for me, a lot of stuff goes in one ear and right out the other unless I get my hands dirty in Eclipse and start thinking critically. So I'm tackling the daunting task of learning Java by going into Eclipse and writing out my own little programs without any cheating (looking on the internet), and then bringing the finished product here to get feedback from you guys. That way I'm actually working my brain and "making it stick" then identifying areas of improvement with your guys'/gals' help.
So I created a program that creates a deck of cards...I got stumped for a little bit and had to restart a few times but eventually I got it right and was actually very pleased with how few lines of code it required; I was expecting more work!
The comments are more for my own reflection and self teaching/self reminding, as I'm sure the workings of the program are obvious to you seasoned Java coders.
Could you please provide some feedback about anything I could've done to make this little program more succinct or more readable, any different approach I could have taken...any feedback basically would be really appreciated. Since I'm doing this all on my own I have no other point of reference to learn better, more acceptable ways of writing programs.
One specific question for feedback I would like to ask: "How would I have achieved the same result with a 2 dimensional array?"
Here's my program, consisting of 2 classes
The output was as I'd hoped; all of the cards being printed out, with none missing. So there's no errors or bugs that I can see, but I'm just asking for your thoughts in general.
EDIT: I just realized that the while loop is unnecessary since the for loops will execute themselves to the end of their arrays without the need for a counter mechanism (but the "c" variable is still needed to plug the completed card strings into deck at index [c])
Nothing is withheld from us what we have conceived to do. -Russel Kirsch-
I agree with Winston and would point you to Item 50 (pp.224-6) of "Effective Java," Second Edition, by Joshua Bloch. (See Item 32 in the First Edition.) Also, see Item 51, which warns against the performance impact of contcatenating strings with the "+" operator. Because strings are immutable (meaning they don't ever change after being created, a feature that seems to bother new programmers, but which ultimately shows itself to have some powerful advantages), concatenating them means that each is actually copied to the new string. The performance impact explodes (that is, grows exponentially) as you add more strings to be concatenated, since each "+" operation copies two strings (thus, a second "+" copies the result of the first "+", a third "+" copies all of that, and so on).
Bloch's book is highly regarded here and, after buying and reading it, I can see why. I recommend it to all Java programmers.
In the other disciplines, we rise by standing on each others' shoulders. In computer science, we do it by standing on each others' toes.
Stevens Miller wrote:Also, see Item 51, which warns against the performance impact of contcatenating strings with the "+" operator.
Whilst you are correct that using + in unoptimised code could have a performance impact, the java compiler is clever enough to recognise this and will optimise the code automatically.
If you were to disassemble the compiled class file with javap you would see that the code in question uses a StringBuilder to create the complete string.
I'll have to try that, but StringBuilder isn't thread-safe, according to the doc.
Joined: Aug 05, 2005
Stevens Miller wrote:I'll have to try that, but StringBuilder isn't thread-safe, according to the doc.
The StringBuilder will be local to the method so doesn't need to worry about thread safety. If any of the String variables being appended are potentially thread unsafe then you would have the same problem whether you used a StringBuilder or String concatenation.
Thanks for all of your feedback, it gave me a lot to think about. Since I'm still learning I'm not the sharpest coder, and I realized that this isn't really a functional program to actually try to make a card game out of because the cards have no value. The only thing that defines them is their Strings. This would mean that I can't really introduce much game logic. For example, if I were to try to implement a method to compare a jack to a king to see which card is higher, the cards have no numerical value and so finding out which is higher in a mathematical manner would be impossible. Kinda difficult to play blackjack and count to 21 when each card has no numerical value!
I need to think this over a little bit to figure out what I need to do to make each card have more values other than a string. I think this might have been what Winston was getting at when mentioning enum.
Justin Coombs wrote:I need to think this over a little bit to figure out what I need to do to make each card have more values other than a string. I think this might have been what Winston was getting at when mentioning enum.
Exactly so, and for the exact reasons you said. Strings are NOT cards, and never will be. A Card class, on the other hand, can be anything you want it to be, and display any way you want to display it. Enums are just a way of defining a restricted value set (such as a Suit or card Value) as a class, and have lots of very useful extras.
well I haven't gotten around to the chapter on enums in the java book I'm reading, but what do you guys think of this revision. It does basically the same thing as the last one, but this time the cards themselves in the array are actually objects
I got stuck on figuring out how to shuffle the objects...any suggestions?
The Collections class has a shuffle() method which shuffles the collection you pass in. The Arrays class has an asList() method which wraps an array in a List wrapper which will allow you to pass in your card array (shouldn't this be called deck) and shuffle it.