This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The problem is in my first program ever, actually, and I had some problems with static methods and variables.
I sorta know what the problem is, but I have no idea how to solve it.
Here's the code for the first class:
This is the code for the second class:
The variables aren't Boolean because it gave me an error when I tried defining them as Boolean.
Ok first of all I am not going to dig into the code itself.
There are far too many problems with your understanding of oop before going there.
You are initializing the program with a public static main method which is a good thing.
The problem is, that you can't call a non static method within a static one without an Object simply because there is nothing to call it upon.
Lets say an object is a black box.
Then your public methods of the class are the only way to look inside this box and do some work there.
Static methods (including the main) are totally out of the object context.
So in your case you could make all methods static (not object oriented) or create a new instance of the DiceRoller and work with this instance.
By the way your "extends DiceRoller" is not necessary, in fact its just not true because there is nothing you are extending.
Okay, I redid the entire thing, with a proper constructor for DiceRoll, and an exit method.
However, Random won't let me insert an integer (in nextInt), claiming that it might be lower then 0.
Or so I though. Now it doesn't even let me use a number!
Please, read the code, and note every single error. This IS my first program, but I don't think there are that much of 'em.
Thanks in advance!
If you want to learn object oriented programing you may want to split your diceroll class. Try to implement the the "objects" you are using in the real world for the task.
Then you should try to define what those objects need to do and what you need to do with those objects.
Try to break it down to what you need for your program.
Your second class should not extend the first one. Why do you think it needs to?
I keep thinking I need the second class to extend the first because it used to not know each other. They were in the same folder, but it didn't work anyway, so I put them in the main folder and it worked. But I though this is everything I needed! Something to change both integers, something to roll the "dice", and something to make sure they all activate in the right order and without any problems. What else do I need? Please be more direct.
I would split it in a dice class and a roller class.
Then I would implement their behavior.
You can choose whats the dices properties are -> constructor of dice.
You can add dices to the roller depending on your choice -> method in roller
you can roll the dice -> method in roller.
and so on...
If classes need to know each other they need to import not to extend if they are in another package.
If they are in the same package that shouldn't be needed.
It works now! I tried spliting it, but that didn't work. So I pretty just much sat with a programmer friend of mine and we both noticed a lot of errors.
So after debugging for two more days, it worked!
Here's the code:
Also, my programmer friend didn't know Java all that well, so when I coded a constructor, he asked me why, and though it's still obvious to me that it needed one, I have no idea why.
Thanks to everyone!
Joined: Oct 13, 2005
Never write == true or == false. Not only is it bad style, but it is very error-prone if you write = instead by mistake. I can see at least one = true in your code.
Not if (b == true) ... but if (b) ... Not if (b == false) ... but if (!b) ...
More iffy design: you appear to have non-private fields, some with the inappropriate and uninformative names like t. Apart from somebody not being able to work out what t means, it is exposing the innards (officially called the implementation details) of your class to the outside world. You should allow access via get and set methods, only if the return type is boolean, we usually call the "get" methods is methods.
You should NEVER be debugging 130 lines of code. If I ever write more than 5 lines without compiling and testing, I start getting nervous. If i should get to 10 lines without compiling, I start getting sick to my stomach.
I am not joking.
It may seem counter-intuitive, but the more time you spend compiling and testing, the faster you will write code.
If I write 2 lines then recompile and get compiler errors, i am pretty sure where the problem is. If i write 100 lines and then compile, there is a pretty broad area to start looking. This is even MORE true for logic errors. Without exception, EVERY time I start a new class, I write this much before I compile the first time:
You'll note that is six lines. And the only reason I write that many is because there's not really a way to write less and see something work. I do this EVERY SINGLE TIME. Then I write 2-3 more lines, and re-compile. I can't emphasize enough how important that is.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
There are competing very common conventions about how to arrange braces. Most IDEs can be easily configured to follow the one you want to use. As long as you're consistent it doesn't matter too much - unless you're working on the same code with other people, in which case you should agree a common approach.
By the way, it's not what you asked, but...using (diceRoll.t == true) isn't great style. And one of the reasons is that it's easy to then write (diceRoll.t = true), as you have above. Now you've got a real problem, because that doesn't do what you might think. That particular loop will never end.
Matthew Brown wrote:By the way, it's not what you asked, but...using (diceRoll.t == true) isn't great style. And one of the reasons is that it's easy to then write (diceRoll.t = true), as you have above.
I hear you, but i just copied that from the thread-starter above as an example about the braces, its not code i wrote myself
Campbell, thank you very much, though that specifically didn't matter one bit, since I used System.exit(0), but I'll use !these from now on.
I'm using that specific code block format simply because my book uses them, and refers a lot to specific lines in code it gives me.
But still, about that compiler bit...
Joined: Oct 13, 2005
Actually, using System.exit() isn't really a good idea. It is safe here, but when you get onto GUIs or other multi-threaded environments, if you use System.exit while something else is going on (eg writing to a file), you terminate all activity. If your file is incompletely written and now corrupted . . .
Joined: Oct 13, 2005
As already mentioned, there are several schools of thought about matching braces. I personally agree with Cai Horstmann who says "braces should line up vertically or horizontally." I heard the other brace convention was designed to save space when screens only had 25 lines of display.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com