I have yet to practice interpreting the logic of the verifier = I have not the faintest idea what its problem is.
1. Familiarize yourself with the code.
2. Accept your fate and keep trying to understand the code.
3. ...
4. Rejoice that you've figured it out.
5. Adapt the code to the following new architecture and add new logic:
5.1. Make the AbstractRobot class abstract. Then move the attack and defend logic from the Robot class to the AbstractRobot class.
5.2. Edit the Robot class to utilize the AbstractRobot class.
5.3. Extend the BodyPart class with a new body part: BodyPart.CHEST.
5.4. Add the new body part to the implementation of the CanAttack and CanDefend interfaces (in the AbstractRobot class).
Requirements:
The AbstractRobot class must be abstract.
The AbstractRobot class must implement the CanAttack and CanDefend interfaces.
The Robot class must inherit the AbstractRobot class.
The logic defining the how a Robot behaves must be in the AbstractRobot class.
The BodyPart class must have and initialize a final static BodyPart variable called CHEST.
The new body part must be added to the logic for the attack and defend methods in the AbstractRobot class.
....
package com.codegym.task.task13.task1328;
public interface CanAttack {
BodyPart attack();
}
I find it extremely unfortunate that the attack and defend methods use the same static hitCount variable.
The == tests aren't good either, I think they should be changed to >= or >= so I don't get null for BodyPart.
I would SURE write this part of the code totally differently.
But the point here is not to write a working program I like, but to try to figure out the verifier's logic and the cunning hidden requirements.
But after about 20-30 verification tests, I am now asking for the opinion of the more successful ones.
It may be you got that problems with validation cause you changed how the given code works. Have a look at the original defend method. Each round the hitCount increases by two. In your code it increases by one. When you change this back you should rethink the last else if clause.
Hi Nouser!
Thank you for your time!
I already tried these versions yesterday which you are suggesting now.
I intentionally tested a different kind of increase in hitCount.
Now I set back hitCount in the defend method to +2 again,
and I changed the last if-else clause again, this way:
else if (hitCount >= 4).
to purpose to never get a "null" for BodyPart.
I tried the following options:
- I wrote this only in the defend method:
(hitCount> = 4)
- I wrote this only in the attack method:
(hitCount> = 4)
- I wrote the same thing in both methods.
But these were not enough for the validator, the same way as these were not enough for him yesterday either:
the fourth requirement is still red:
"The logic defining the how a Robot behaves must be in the AbstractRobot class."
I have no clue if you need to move everything to the abstract class. In that case name should be there, too (but I doubt CG asks for that). But the child shouldn't be able to modify data related to attacking and defending in the parent. Therefore I'd encapsulate hitCount more (as it already was originally).
For the chest I didn't do any check but made it catch all the rest.