posted 18 years ago
In this case, you've got only one class, so the get/set methods part really doesn't apply. But as to public vs. private variable and the general style questions... yes, you have some changes to make.
The first, most obvious one: member variables -- variables declared in a class body -- should with very few exceptions be declared private, not public. That's a trivial change, I'm sure you'll agree. Making variables private supports encapsulation, an important principle of object-oriented design -- consult your textbook for details.
Second, making everything static like this is bad style. Instead, make nothing static except for main(), then change the body of main to look like:
Again, we're working toward object-oriented principles here; in this case, simply by using an HCF object rather than not.
Third, most of the time, methods should communicate by parameters and return values, not by passing things through member variables. If you want to give your friend a beer, do you do it by putting the beer on a shelf and asking him to take it off the shelf? No, you do it by handing the beer to him directly. The same thing here: one method shouldn't pass data to another by putting data into a member variable for another to find: it should instead pass the data as method parameters.
You've done a little bit of this, but it looks like you're being tentative about it. The method gCt (awful name, by the way; can't even guess what it means. Don't be afraid of long names if they're easier to understand!) The method gCt accepts two parameters named firstInt and secondInt, but it also refers to members num1 and num2. The method Enter passes the two parameters in, but it also leaves copies in num1 and num2. So gCt is using two different copies of those same two numbers -- which is confusing to read and error prone. The fix is to eliminate the member variables num1 and num2 altogether. First, move the declarations from the class scope into the method Enter. Now gCt won't compile anymore, so you'll need to change num1 into firstInt and num2 into secondInt in that method. Now those two methods communicate directly, just like handing a friend a beer.
But wait -- there's more! What about the "rest" and "factor"? These are both declared at class scope, and yet they're not used by any other method. Close inspection shows that they're not communicated between recursive calls -- i.e., one recursive call won't read values set by another recursive call. Therefore, they can both become local variables inside gCt. You can move menuPoint also using similar logic.
Yet another point: gCt returns a value, but is that value ever used? Nope. There are two possibilities, then: gCt could be changed to just return void, or gCt could be changed to return a value but not print it; the caller should print the return value instead. The second option is much better: ideally a method should just do one thing, and computing a value and displaying it counts as two.
I hope this helped.