Re: Beginner doubt about access and methods
Jordi wrote:
Hello,
thanks you all for the opinions.
I use Serializable because I need to send my objects through the
network in a bigger program that I have written.
You can forget about that detail.
But you can't. Pay attention to Tom Hawtin's advice about Serializable:
By making your class serialisable you are effectively opening up a second interface onto the class. Try to avoid exposing the implementation as much as practicable. So much grief had been caused by adding implements Serializable without thinking further. serialVersionUID should also be present.
Read Joshua Bloch's chapters on the subject in /Effective Java/. There is a
lot to take care of if you make a class Serializable.
I take note on making the methods final, as they will remain that way
on the classes that inherit this.
That is a good thing. Remember not to invoke overridable methods from
constructors.
It is abstract because there will be no instance of this class.
I need to create near 20 or 30 classes based on one abstract class.
My reason to use inheritance is not to have to repeat 20 or 30 times
the same code, so all becomes really confusing. Is this right?
Maybe. If your analysis indicates that the 20 or 30 types /are-an/ instance
of the supertype, then inheritance is the way to implement that. Re-use of
common base functionality is a strong but not compelling argument in favor of
using inheritance.
Note that code duplication can be prevented without inheritance by using
composition, instead including a helper-class object to handle the common
functionality. For example, most situations that call for a collection, say a
Map, should use a Map instance member rather than inherit or implement Map.
Again, this is a topic well covered in /Effective Java/.
I need to set some variables each time I create the instances of
subclasses. This may be done simply with constructors.
I create the get and set methods for if I need to change some value .
Do you think this is right?
If you make the methods final, most likely. However, there is an argument in
favor of not having the setX() method, making the instance variable final, and
simply creating a new instance of the object if you need a new value. For one
thing, it can make your code much more efficient. For another, it prevents
override abuse. For a third, it simplifies concurrency issues.
This is called making the class "immutable", or more correctly, making all its
instances "immutable". (The term is approximate - as others have pointed out
elsethread, nothing is ever completely "immutable" in Java.)
The trick is whether your design calls for the methods to be overridable.
Another topic thoroughly covered in /Effective Java/.
--
Lew