To reduce code duplication and its total size

Apparently, the teacher spotted a lot of identical fragments in your code and suggested putting the repeating parts in a separate place. An abstract class is a fairly typical way to do this in OOP languages. Not universal, but more or less everywhere.

In programming, this desire is known as DRY (Don't Repeat Yourself, Do Not Repeat). This achieves several pleasant moments:

• The amount of code becomes less, the chances of making mistakes in it are less.
• Making changes to this repeating code snippet, if necessary, is likely everywhere. And it's easier to do it in one place than in all classes separately. Again, the likelihood of making mistakes is reduced.

But do it carefully.

It’s easy to get used to the fact that "putting duplicate code into a class" is always a good idea.

But it is not. And with such an approach it is easy to get stuck in a situation where in any one case the implementation of an abstract class just doesn’t suit you, since the "common part" put into it is slightly different. Well, if you can override desired method (although not, not very well, see below), but the situation explodes if you are forced to make another, very similar class.

And then, following the principle of "making common parts in a separate class," you get another level of hierarchy and the code becomes much more complicated than necessary. The problem seems to be solved, but the code starts to resemble a dense dark forest.

Where is the mistake? In abstraction. Sometimes it is necessary to endure not all common parts, a little duplication can be left if this is seen as a specific part for a specific heir, and heirs without it are possible.

"duplication is far cheaper than the wrong abstraction"

"it is much easier to live with duplication than with abstraction curve"

It is necessary for your code to comply with the principles of OOP.

Why do I need OOP? - the question is very voluminous, you can read about it, for example, here .

Concerning an abstract class, an irrelevant example:

There are two classes: Cat and Dog , each of which has a field for the name of the animal and a certain method makeNoise() (you have it now):

 public class Cat { private String mName; public Cat(String name) { mName = name; } public void makeNoise() { System.out.println("Meow!"); } } 

 public class Dog { private String mName; public Dog(String name) { mName = name; } public void makeNoise() { System.out.println("Woof!"); } } 

You can define the abstract class Animal and its subclasses Cat and Dog (this is what they suggest you do):

 public abstract class Animal { private String mName; public Animal(String name) { mName = name; } public abstract void makeNoise(); } 

 public class Cat extends Animal { public Cat(String name) { super(name); } public void makeNoise() { System.out.println("Meow!"); } } 

 public class Dog extends Animal { public Dog(String name) { super(name); } public void makeNoise() { System.out.println("Woof!"); } } 

The abstract class defines some structure of its subclasses: both the cat and the dog can make sounds (the abstract method makeNoise() defined in the superclass, but they make different sounds (each of the subclasses uses its own implementation of the makeNoise() method).