Stephan van Hulst wrote:I would recommend having a private static Random in the Gesture class, and a static Gesture.random() method that returns a random Gesture using the static random number generator.
As for naming parameters, when I want to compare this instance to a method argument of the same type, I tend to name the parameter 'other', for instance: compareTo(Foo other) or beats(Gesture other).
Michael Bruce Allen wrote:
Your assumption is correct. I felt it was redundant. Why is it unorthodox? What would you have used?
Michael Bruce Allen wrote:I like the ability to call Gesture.getRandomGesture() without instantiating Gesture to call that. (now that I look at it Gesture.getRandomGesture() looks redundant)
Michael Bruce Allen wrote:Still though, I do not like this code and I cannot figure out exactly why.
Junilu Lacar wrote:
You're making progress. You have some sensitivity to redundancy now. There are many others who would just walk right by that and not even bat an eyelash.
....
You don't have to qualify the static values() method with the enum name when you reference it from within Gestures itself. That cuts down on the noise. Since values() returns an array, you can get to any particular element in it using array index notation.
Michael Bruce Allen wrote:I really feel like I am 10 times better in just 1 day.
Junilu Lacar wrote:...
Your return expression is fine, too. Alternatively, you could get cute and use the expression (moduloAlgorithm % 2) != 0 instead. That's the idiom for an odd number filter although you could argue that it would return true for other odd numbers even though you wouldn't expect them to ever occur. (moduloAlgorithm % 2) == 0 is the idiomatic expression to return true for even numbers (also called a "filter expression").
Stephan van Hulst wrote:For the calculator, I think you need to take a small step back with the TDD, and think about the overall design a little bit first. After all, you can't write tests if you don't know what you're going to work with.
Eventually, you want to create a graphical application that can perform mathematical calculations in both infix and postfix notation. You need a common interface to be able to plug it into the graphical calculator. So what do infix and postfix calculations have in common? They make expressions out of input tokens:
...
Now, it's your job to think what you want to know about a Token, and write tests for the expectations you have of Token and Calculation. Finally, you can implement this behavior.
Michael Bruce Allen wrote:This is for learning now. I feel like I am writing these tests just to learn how the code works.
Michael Bruce Allen wrote:So how can I accomplish this same thing while creating the right tests?
Junilu Lacar wrote:I've said this before and I'll say it again, but I really think you should skip parsing for now. Parsing is a lot more complicated than you think and I'm afraid you'll just get bogged down in the details. I suggest that you assume you've already parsed the input into the proper data structures for postfix notation.
Michael Bruce Allen wrote:I am just looking for a goal or plan here. I do not mind figuring out the parsing. I think I understand how to do it and with recursion it should be doable. But then again, I have never written anything with recursion or ever parsed strings like this, so what do I know
Junilu Lacar wrote:(Continued... simulated TDD conversation)
So now can I implement the add() method?
Well, it's tempting to do that but let's stay with the TDD cycle. There's not much to refactor right now, even though we know result() has a bogus implementation. The next step is to repeat the cycle and "Write a test and see it fail."
What test should we write now?
There are a couple of ways we can go about writing a new test :
1. Write another test to specify a different behavior we want to see from the calculator or
2. Write another test to show that the implementation of the result() is really bogus
Which do you think is the right one at this point? Why?
Michael Bruce Allen wrote:
I say number 1, because until I am very sure that it is calculating properly, I want to use that "bogus" implementation. But I truly do not see what it is bogus right now.
Junilu Lacar wrote:
....
So again, I'll ask:
There are a couple of ways we can go about writing a new test :
1. Write another test to specify a different behavior we want to see from the calculator or
2. Write another test to show that the implementation of the result() is really bogus
Which do you think is the right one at this point? Why?
Michael Bruce Allen wrote:
I say number 1, because until I am very sure that it is calculating properly, I want to use that "bogus" implementation. But I truly do not see what it is bogus right now.
Michael Bruce Allen wrote:Thank you for the response Junilu. And thank you as well Stephan. I am going to keep Stephans response available until I do a few more small steps and then I will delve into that structure a bit more. It looks really interesting.
Michael Bruce Allen wrote:I did a bit of coding and about the time when I realized that I wanted the array to have the information in reverse, I thought, perhaps there is a Stack class.
Junilu Lacar wrote:That's a lot of code. How much refactoring did you do? From what I see, it can't have been much. That's way too much code to write without refactoring. In fact, the 7 lines of program code and about as many lines of test code that I added already is smelly enough to warrant a few minutes of refactoring.
You have to learn to catch yourself when you do that. That is, when you thought, "I want the array to have the information in reverse", you have to ask "What's telling me that?" and if the answer is not "This failing test is telling me that." then back up and write the test.
Michael Bruce Allen wrote:
have questions on commits:
When should I commit? At a fail? Or at both a fail and a pass? Or at every little detail?
Michael Bruce Allen wrote:Right, once I wanted to do multiple additions or subtractions, I realized I needed a better feature then an ArrayList and it was either write some code to manipulate ArrayList or find a Stack type list.
That's a lot of code. How much refactoring did you do? From what I see, it can't have been much. That's way too much code to write without refactoring. In fact, the 7 lines of program code and about as many lines of test code that I added already is smelly enough to warrant a few minutes of refactoring.
Michael Bruce Allen wrote:So the question is, now that you have seen my commits, you feel I have moved to quick?