Ok... so I have a huge problem here, I am taking CSE 143 and am having trouble understanding it, and I've been working on this program and am going to take whatever crappy amount of points I can get, and I see stuff that is wrong with it BUT I JUST DON'T KNOW HOW TO FIX IT. And I know that there is a ton wrong with it and I don't want anyone to write my code, but any kind of ideas or something on how I can understand this stuff would be appreciated.
This is supposed to create a letter inventory and then do all of these different methods for it, so I'll leave in some of the comments I had so it's hopefully kinda clear... I'm really scared I'm going to fail this class
I can only offer a few general pieces of advice at this point:
1) UseAMeaningfulSubjectLine(←click). The subject is there to convey the nature of the specific problem that you're asking about. We already know you need help, else you wouldn't be posting here, and the fact that you're desperate is not really of any relevance to your question or of any concern to anyone here.
2) TellTheDetails(←click). All we have to go on now is a big wad of code and a vague, "something is wrong and I don't know how to fix it." Here's the thing: We don't know how either, because we have no idea what you're talking about. You need to be clear and precise about what exactly you're trying to do and what exactly is going wrong. If there are compiler errors or exceptions at runtime, copy/paste the exact, complete error message, and indicate clearly which line is causing it. If there are no errors but it's just not behaving like you want it to, be specific about what it's supposed to do and what it's doing instead.
3) This one is the most important, and will be the hardest for you to swallow right now. Attack the problem in small pieces. Throw away all the code you have there and start from scratch. Write one tiny piece. The tiniest piece you can get working, even if it's jsut "Hello World." Once that piece works, add a tiny bit onto it and get that piece working, and so on. At some point you'll probably want to start a completely separate program to test some new piece independently from what you've done so far. Once you get that piece working, incorporate it into your overall program. Hardcode test values and don't worry about user inputs or reading files, etc. until you've got a piece working with hardcoded values.
Breaking into pieces and attacking them one at at time not only makes it easier for you to solve your overall problem, it also makes it easier for you to ask a clear question when you get stuck and easier for us to understand what you're trying to do, identify what's wrong, and guide you toward fixing it. (Review #2, and understand how much it depends on #3.)
Start with that. Get it working, making sure that it always returns 123.
Next step might be to add String str = "AA" inside the method body and make sure it reuturns 2 when you pass 'A' and 0 for various other test inputs. Then hardcode "AB" and check for 1, then "BB" and check for 0, and so on, including error conditions.
Next step might be, "Okay, I know I need to pass a name to the constructor and store that as a member variable." So do that. Change the c'tor to accept a name, and have main print out the name from the newly created LetterInventory object.
Next step might be to go back and change get to use the member variable and get rid of the hardcode "String str = ..." in the method. Then your main can have several tests like:
I know this sounds like a lot of work, but believe me, once you've got past the first couple of rounds, you'll be able to make and test changes very quickly, and since you're only changing a little bit at a time, it will be easy to track down any errors that pop up.
Joined: Oct 04, 2012
Ok right I was just a bit panicked, I appreciate the help everyone. I'm just going to go through this bit by bit and see what happens, thanks
Did you write all that code, or was it handed to you and now you have to 'refine' it? If the latter, we can lump our way through it. If the former, my advice is: Throw it all away. Not because it is bad, but because there is TOO MUCH THERE to start with.
Never, never, never, never, never, never, never (I can't say that enough) write more than a few lines before you compile and test. Every single time I start a new java program, I write this much before I compile the first time:
I compile and run it, and make sure it does what I want. Then, I may write as many as TWO lines before I do the next compile/test/debug iteration. Then two more.
You need to only work on one thing at a time. learning how to break down a requirement into discrete tasks is critical. Even this:
Can be broken down into at least five discrete things that need to be done. And i would do each of them separately - making sure the first one works before even THINKING about doing the next one.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors