David J. Barnes, Michael Kölling (2007). Object Oriented Programming with Java A Practical Introduction Using BlueJ (3rd ed.)
10.4 More abstract methods
….In Java, fields are handled differently than methods: fields cannot be overridden by subclass versions.
...
This rule applies regardless of whether a field is static or not.
So fields are just inherited and methods are overridden...is that correct?
It refers to the fact that the methods of a superclass can be overridden in a subclass, modifying the behavior of said method by means of
@Override
Fields (attributes, members, of a class) cannot be overridden, they are inherited.
If you have for example:
The
name
class fieldSubType
is not an overridename
of the class fieldSuperType
, they are simply two different fields. Standing at SubType you can access it by:¨
Although the answer has been published and accepted for a while; to add something more about abstract methods:
The purpose of an abstract method is to allow classes that inherit from it to implement a method in different ways. This mechanism is essential to make use of polymorphism, one of the main concepts of object-oriented programming, as well as most of the most used design patterns.
I am going to give you an example with a circus, in which there are artists such as jugglers, fire-eating clowns. Each of these artists greets, does their number and says goodbye.
We start to make the artist class, with the method say hello and goodbye (all artists do it the same way.
So far so good, but now we have to implement the way each artist acts, and we can't know this until we know which artist we're talking about.
So we can say that the method to act is abstract and let its child classes be the ones that implement the method.
Now we can define the child classes, we only need to implement the abstract methods in principle since the methods of the parent class are inherited.
Now that we have our circus set up, we can start the performance:
Departure:
Note that here we create a list of artists and we are creating artists of different types, in this case a clown and a fire eater. Each of the artists will greet, perform and say goodbye. In the for loop we don't know until we're running that code exactly what type the artist is (we just know that it's a child of the Artist class).
When the hello method and the goodbye method are executed, the corresponding methods of the Artist class will be executed, but when the act method is executed, the method of the corresponding class will be executed depending on the type of artist we are iterating over .
At this point you may ask yourself, and can't you do the same thing with an if, consulting the type of each artist? Something like that:
The problem with this is that as the application grows you will find that you repeat that if many times, which can introduce copy/paste errors. Also, if you have the code full of those ifs, what happens if a new artist arrives: The tightrope walker. You would have to go to all the ifs to add that condition so that your application does not fail.
Finally, keep in mind that adding an abstract method to a class has two effects:
This force is especially interesting, since by using abstract methods wisely, you can influence the way classes are reused.
Imagine that you have a class that generates a very complex report and saves it in a DOC file. You know that another programmer is going to have to do the same thing but is going to have to save it to a PDF. You want the generation of the report to be done in the same way but only the way in which the result is saved is changed. You could do something like this:
If you orient the methods in this way, whoever wants to generate a report in another format such as PDF, HTML, etc, will only have to create a class that extends ReportGenerator, and will be forced to implement the writeResult method. That person will not need to know how the report is generated nor will they need to make any changes to that method.