solved all tasks#2610
Conversation
mateacademy-ai-mentor
left a comment
mateacademy-ai-mentor
left a comment
There was a problem hiding this comment.
Review Summary
I am requesting changes because there is a clear mismatch with a critical requirement about the printed messages, and this is explicitly called out in the checklist. Right now, all doWork() / stopWork() implementations print generic texts like "Machine started its work" / "Machines stopped working" instead of naming the concrete type (Truck, Bulldozer, Excavator), which violates the requirement that the output indicate which machine is working [CHECKLIST ITEM #2]. To fix this, update each subclass so that its messages are specific, for example in Bulldozer.doWork() (around line where you print now) use a string that includes the word Bulldozer, and similarly in Bulldozer.stopWork() use a singular message like "Bulldozer stopped working"; repeat this pattern for Truck and Excavator. These messages are part of the functional description, so tests or automated checks are likely relying on them being exact per machine type, which makes this a blocking issue.
A separate, non-blocking issue is style-related: there are extra blank lines directly after class declarations and between method declarations in Machine, Truck, Bulldozer, and Excavator, which goes against the style checklist [CHECKLIST ITEM #1]; once you adjust the messages, also clean up those redundant empty lines. Structurally, you’ve done a good job: Machine is abstract with doWork() / stopWork(), the subclasses extend it correctly, and MainApp uses a Machine[] and a loop to invoke methods polymorphically. Once you make the message texts machine-specific and tighten up the blank lines, your solution will fully meet the task requirements and be in great shape.
✨ Please rate this review in the Platform's notification center1. I will be grateful for your feedback! ✨
Important
Fix the issues, commit the changes, and then re-request my review using the Re-request review button2 in the Reviewers tab.
Tip
If you have any comments about this review, please leave a message in the Add a comment section below and mention me with the @mateacademy-ai-mentor tag3.
I will read your message during my next review of your pull request. Please do not reply directly to my comments, as that feature is not supported yet.
Caution
Do not close the pull request until the review is complete. Closing it early can lead to unexpected behavior and disrupt the review process.
Footnotes
| public class Bulldozer extends Machine { | ||
| @Override | ||
| public void doWork() { | ||
| System.out.println("Machine started its work"); |
There was a problem hiding this comment.
This violates checklist item #2: "The message should indicate what type of Machine is working right now Truck, Bulldozer or Excavator." Consider including Bulldozer in the message so it’s clear which machine started working.
|
|
||
| @Override | ||
| public void stopWork() { | ||
| System.out.println("Machines stopped working"); |
There was a problem hiding this comment.
This also violates checklist item #2, because the message doesn’t specify that a Bulldozer stopped working and uses plural "Machines". Make the message informative and specific to Bulldozer.
| public class Excavator extends Machine { | ||
| @Override | ||
| public void doWork() { | ||
| System.out.println("Machine started its work"); |
There was a problem hiding this comment.
This message is too generic and does not indicate that this is a Bulldozer; it violates checklist item #2: "The message should indicate what type of Machine is working right now Truck, Bulldozer or Excavator." Consider including the specific machine name in the message.
|
|
||
| @Override | ||
| public void stopWork() { | ||
| System.out.println("Machines stopped working"); |
There was a problem hiding this comment.
This message is generic and plural ("Machines"), and it doesn’t specify that the Bulldozer stopped; this violates checklist item #2 about informative, type-specific messages. Update it to mention Bulldozer explicitly.
| public class Excavator extends Machine { | ||
| @Override | ||
| public void doWork() { | ||
| System.out.println("Machine started its work"); |
There was a problem hiding this comment.
This message is too generic for Excavator and doesn’t mention the concrete machine type, violating checklist item #2 about indicating which machine is working.
| machine.stopWork(); | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
This stopWork message should also clearly mention Excavator to be informative and machine-specific, as required by checklist item #2.
| public class MainApp { | ||
|
|
||
| public static void main(String[] args) { |
There was a problem hiding this comment.
There is an extra empty line after the class declaration, which matches the "Bad example" pattern in checklist item #1 about redundant empty lines after class declarations.
| Machine[] machines = {new Truck(), new Bulldozer(), new Excavator()}; | ||
| for (Machine machine : machines) { |
There was a problem hiding this comment.
The empty line between these abstract method declarations matches the "Bad example" pattern in checklist item #1 regarding redundant empty lines; consider removing it.
| public class Truck extends Machine { | ||
| @Override | ||
| public void doWork() { | ||
| System.out.println("Machine started its work"); |
There was a problem hiding this comment.
This message is generic and does not indicate that it is specifically a Truck that started working, violating checklist item #2: "The message should indicate what type of Machine is working right now Truck, Bulldozer or Excavator." Update it to mention Truck.
|
|
||
| @Override | ||
| public void stopWork() { | ||
| System.out.println("Machines stopped working"); |
There was a problem hiding this comment.
This stop message is also generic (and plural "Machines") and doesn’t specify that Truck stopped working, which violates checklist item #2. Make it informative and specific to Truck.
mateacademy-ai-mentor
left a comment
mateacademy-ai-mentor
left a comment
There was a problem hiding this comment.
Review Summary
Your solution is approved because all core functional requirements are correctly implemented and there are no blocking issues. The Machine class is properly declared as abstract with public abstract void doWork() and public abstract void stopWork(), and Truck, Bulldozer, and Excavator correctly extend it and override both methods with clear, English messages that mention the specific machine type. In MainApp, you use a Machine[] and iterate over it to call doWork() and stopWork() polymorphically, which satisfies the abstraction and polymorphism requirements.
The remaining observations are minor style points: there are redundant empty lines after the package declarations and between method declarations in Excavator.java and Truck.java, which the checklist asks you to avoid ([CHECKLIST ITEM #1]). For example, remove the blank line right after package core.basesyntax; and avoid extra blank lines between consecutive method signatures or implementations. These are cosmetic and will not block your progress, but cleaning them up will make your code more consistent with typical Java style guidelines. Overall, you met the task’s functional and design goals well.
✨ Please rate this review in the Platform's notification center1. I will be grateful for your feedback! ✨
Footnotes
| @@ -0,0 +1,13 @@ | |||
| package core.basesyntax; | |||
|
|
|||
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between the package and class declaration is considered redundant per that guideline.
| public void doWork() { | ||
| System.out.println("Excavator started its work"); | ||
| } | ||
|
|
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between method declarations is one of the patterns they ask you to avoid.
| @@ -0,0 +1,13 @@ | |||
| package core.basesyntax; | |||
|
|
|||
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between the package and class declaration is considered redundant per that guideline.
| public void doWork() { | ||
| System.out.println("Excavator started its work"); | ||
| } | ||
|
|
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between method declarations is one of the patterns they ask you to avoid.
| @@ -0,0 +1,13 @@ | |||
| package core.basesyntax; | |||
|
|
|||
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between the package and class declaration is considered redundant per that guideline.
|
|
||
| public class Excavator extends Machine { | ||
| @Override | ||
| public void doWork() { |
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between method declarations is one of the patterns they ask you to avoid.
| @@ -0,0 +1,13 @@ | |||
| package core.basesyntax; | |||
|
|
|||
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between the package and class declaration is considered redundant per that guideline.
| public void doWork() { | ||
| System.out.println("Truck started its work"); | ||
| } | ||
|
|
There was a problem hiding this comment.
This violates checklist item: Please don't add redundant empty lines to your code. We don't need them after class declaration or method signature. The blank line between method declarations is one of the patterns they ask you to avoid.
4 participants
No description provided.