|Java Class Inheritance|
|Written by Mike James|
Page 2 of 5
This may seem a time wasting idea but now imagine that you need to change how a point is represented within the class, perhaps as an angle and a distance. You could leave the outside world working with x and y and use the set and get routines to do the conversion.
This might seem like a lot of work but NetBeans gives you an option that will automatically convert any variable declarations in the class into setters and getters. For example, if you start off with
and right click in the code at the point you want to insert the functions and select insert code, you can select automatic setter or getter generation:
If you select Getter and Setter then you presented with an additional dialog that allows you to selected which variables you are going to add getters and setters for:
When you click the Generate button the code you need will be created:
Over time getters and setters have become the accepted way of implementing properties in Java and in other languages. Notice however that the use of getters/setters is no part of the Java language and it is a convention - so strong a convention that NetBeans provides tools to help you implement it.
Well a lot of object oriented programmers drop the set and get idea mostly out of laziness rather than by way of an informed decision but you should recognize the set/get idea as how Swing implements its properties. All properties of Swing objects such as buttons work with set/get methods. If it is good enough for Swing and the majority of other libraries it should be a recommendation you take notice of.
Some programmers take this idea one step further.
They hold to the view that an object should never give up any data. If something needs to be done to a property then the object should do it not pass the data out to another object to process. This stronger position is a little more controversial and most programmers strive for an ideal but are happy to compromise is there is a pay off.
When you first create an instance of an object there is often the need to initialize it before using it. The obvious thing to do is to write an “init” member function and remember to call this before going on.
The trouble with this idea is that you could forget to use init before getting on with the rest of the program. To help avoid this Java and most other object oriented languages use special functions called constructors that can be used to automatically initialize a class.
A constructor has to have the same name as the class and it is called when you create a new object of the class. For example, if we add the constructor
to the point class you can create and initialize a new object using
Notice the way that the values to be used in the initialization are specified. In fact you can think about the use of Point(10,20) as being a call to the constructor.
As well as an initialization routine, you can also specify a clean up routine called finalize() that is called whenever an object is about to be deleted. This isn’t used as much as the constructor but it is still handy.
If you don’t bother to write a constructor the Java system provides a default constructor that does nothing and takes no parameters.
If you define a constructor of any sort the system doesn’t provide a default. So if you define a constructor that takes parameters, e.g. point(x,y), don’t forget to also define a parameter-less constructor, i.e. point(), if you also want to create objects without any initialization or with a default initialization.
It is worth knowing at this early stage that the whole subject of initializing objects is a complicated one that has lots of different clever solutions.
For the moment knowing about constructors is probably enough.
The previous section introduces a new idea. You can define any number of constructors as long as each one has a different set of parameters. This means you have functions i.e. the constructors all with the same name, the name of the class, differing only by the parameters used to call them. This is an example of overloading.
Although it doesn’t actually have anything directly to do with object oriented programming, and so rightly should be left until some other time, overloading is too useful to postpone.
The general idea is that you can have any number of functions with the same name as long as they can be distinguished by the parameters you use to call the function.
In more formal terms the “signature” of a function is the pattern of data types used to call it. For example,
has a signature int,int and
has the signature float,float, and
has the signature int,float and so on…
When you call a function for which there is more than one definition the signature is used to sort out which one you mean.
In this sense you can consider that the name of a function is not just the name that you call it by but its name and types of parameters. So Swap is really Swapintint, Swapfloatfloat and Swapintfloat and so on. But notice that this is just a handy way to think about things you can't actually use these names.
For example, given the multiple “overloaded” definitions of Swap given earlier, the call Swap(x,y) where x and y are ints would call the first Swap, i.e. the one with signature int,int. As long as the function used can be matched up with definition with the same signature everything will work.
What function overloading allows you to do is create what looks like a single function that works appropriately with a wide range of different types of data.
You can even define functions with the same name that have different numbers of parameters. For example, Swap(int a, int b, int c) has a signature int,int,int and thus is a valid overloaded form of Swap.
As already mentioned of the most common uses of overloading is to provide a number of different class constructors. For example, you could create a point(int a) constructor which only initializes the x data member or the point(float r, float t) constructor which sets x and y from a radius and an angle.
Notice a function’s return type is not part of its signature.