It had been passing by more than a decade since I coded my latest JAVA project. That in mind, after finishing this course, I thought to refactor my HackAssember, because I didn't take to much advantage of object oriented structure in some parts and at the end I did not implement all proposed methods of the Parser API.
This time I try to implement the Assembler following the project guidline. (as Java programming excercise). But there are some methods which design I would put into question.
Is there any design reason why not all of those should instead return Strings? I mean the results are not used for any type of calculation and at the end spit out into the .hack file as strings anyway. If I handle those as strings from the beginning I don't need any conversion in between.
Or do the proposed return types result of any design principles or patterns that I'm not aware of?
You can implement it any way you wish -- the proposed API is merely one that is suggested by the authors.
At some point you have to deal with the addresses as integers, if for no other reason than to determine what the address of the next variable will be at. If you want to store them in the table as binary-encoded strings, that is perfectly reasonable.
I suspect that the reason the authors return an address as an int is that most people writing the code will think of an address as an int, and not a string of 0 characters and 1 characters, and mixing the two, though quite reasonable, would be unnecessarily confusing for too many readers without a lot of additional explanation.
With the intention to give it a 2nd try and to improve my working Assembler solution I was maybe overthinking it to much. Thank you for your opinion. I'll go on with reworking my program structure but keep my chosen data types then. :)
There is one advantage to using the authors' API, from a practical standpoint. It is good practice in programming to an API specification, which is something that most software developers have to do a lot of. This frequently involves inferring what the logical organization of the program has to be in order to comply with someone else's vision of how the program is partitioned -- something that is usually not that easy and therefore is something that is worth practicing.
Sometimes it is an exercise in frustration because we see some obviously better ways to do it, and other times it is eye opening because we see how someone else approached it that we would have never thought of and that expands our horizons. It's not uncommon for it to be some mixture of the two.
I'm not going to tell any more than: I changed the java reference class which handles my input file and suddenly all proposed Parser API methods make perfectly sense.
I guess when I'm done with it, I'll test run both applications on Pong.asm and find out, which one assembles faster. hahaha
It was anyway a good repetition of Java's basic libraries.
If an old wise man advices you to buy a pet to make your kids happy, you do so and your kids are perfectly happy, but you wonder about the instruction to take the pet out for a walk every day, you should not think about best practice of walking with the goldfish. You should think about if the proposed pet maybe was a dog.
Whilst working through the chapters that required me to do some coding and having skimmed through them first, before actually "doing" the chapter properly: by the time I'd got to the API I'd already thought about roughly how I'd do it anyway, and totally ignored the suggested authors API (I'm not on any course, so have some freedom as it were). Perhaps not surprisingly there still ended up being some similarities between my program and the suggested API even when i wrote stuff in C. As WBahn says, as long as it works (though if you've got the time doing it in style is a bonus !)..
(Sorry that opening sentence is terrible but I can't think how to re-organise, gotta get back to work..)