No. Floating points type should not be used to represent exact values. If your allowed values have a finite precision, you can use BigDecimal. If your allowed values are rational numbers with infinite precision, you will want to write a custom Fraction class.
What does a value of 1.2 for specialAbility mean? Is it a score? Then you might want to add a suffix like Score to your variable name to make that clear.
If you want special ability to grow more slowly, you can still use an int and a scaling factor, say 10, and use integer division.
Say you use 10 as a scaling factor, then both 21 and 29 will give you 2 (using integer division, 21/10 and 29/10 both give 2) so special ability will have to be incremented 10 times before it goes from 2 to 3.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
The setName method should simply take a name String and set the value in the class.
posted 10 months ago
firstly the method should be
no need for String as its not returning anything.
so should all input output be done in the main class?
posted 10 months ago
No, it should be done in one or more UI classes.
That way, when you decide to change the type of UI (eg move from a console UI to a Swing or FX UI) you don't have to change the "business" logic of your code to any great extent.
A setter for 'name' should follow this template by Java conventions:
Notice, no user interface allowed. If you want a method the prompts the user for values then call it something else, perhaps
Or even better, don't put UI code inside this class at all.
If you have a UI class you can design it like a utility with static methods. You might have a method
As a user, I would be annoyed with a program that was constantly bugging me, "is this correct?". In the example above the character has a number of attributes, I'd have the program get them all, then print them all, and only then ask if the character is correct. Not for each individual attribute. If they say no, then repeat the questions using the previous input as the promptXXXWithDefault() value. This allows them to quickly step through the prompts hitting Enter until they get to the attribute they want to change. -- Having said all that, I think your first cut of the program should just assume all the entries to be correct, and add this additional logic after you've got all that debugged.