7 Messages with parameters

Rudolf Pecinovsky

Contents of whole series

Note:
You can download the project we will use in this lesson here.

Relevance of parameters

You talked about parameters when we stared to send messages asking for creating new instances. What is so curious about it that you give it a whole lesson?

Programming starts to be really interesting only after introducing parameters. Parameters allow specify in detail what you want the addressed object to do. With messages without parameters we were often dependent on the default setting and it often doesn't suit our needs.

Work with parameters is easy. When you want to send a message with parameters, BlueJ opens a dialog box where it prepares a text field for each parameter. Next to it BlueJ writes the name of the corresponding parameter and its type. From the name of parameter you can often successfully guess its purpose.

Besides BlueJ copies into the dialog box the documentation comments. So if the class was prepared by a good programmer, you would have all the information to enter the right values.

Parameterized construction of objects

I would welcome some example.

Well. We start again with the reset of the virtual machine and then we try again letting the class Test create our “favorite” three part object consisting of a rectangle, an ellipse and a triangle. However this time we will have them created in another position and with another size. We begin again with a rectangle. For its creation we send the message

new Rectangle(int x, int y, int width, int height)

As you see, this message has four parameters. The entry of particular parameters in the parenthesis after the message name we term parameter declarations. Every declaration begins with a type of particular parameter followed by its name. Particular declarations are separated with commas.

The declared type tells you which sort of information you should enter and on the other hand it tells the computer what to expect. In such a way we increase the efficiency of running programs, and especially we decrease the number of mistakes we make in writing the program. I return to this subject again several times in the future.

But how I should enter the parameter values?

I have already said. When you enter a command for sending a message with parameters, BlueJ opens a dialog box where it asks you for the parameter values. When you ask for creating a new instance, it adds in the dialog box a text field for the name of the reference to this instance.

Figure 1: Dialog box for entering parameter values

We make the rectangle twice as large as the previous one and moved a little from the border to the center of the canvas. We accept the offered name of the reference to created object and enter the position [50; 50], width 200 and height 100.

When we created our first instances you talked about name of instance. Now you are talking about name of reference. In the last lesson I understood that these are different things.

You are right. At the beginning I didn't want to complicate the explanation and therefore I talked about names of instances. However now you already know that we can have several references to one instance and that the named entities are not instances, but references to them.

I don't like that the authors of BlueJ use the term name of instance, but I know, that the students soon abandon reading texts in dialog boxes and therefore I won't try to change it. It is important to know, what the differences between these terms are and respect it in your programs. The rest are only formalities.

Well. I entered the values you requested and I immediately added also the remaining two objects and enter for them the same values of parameters.

You could have utilized that every parameter text field in these dialog boxes has a pull down list with the last entered values of that type, however it is no problem; you can try it next time.

We now supersede the original text fixture with the just created trio. Ask again the class Test for creating a test fixture. When it warns that it already has a fixture declared and asks, if you want to replace it, answer Replace.

Figure 2: Request for confirmation of demand for replacing the fixture

Now try to run again both prepared tests. If you acted according to my suggestions they would both work.

Once more object versus reference

You are right, it works! However, why does it work although we have in the fixture completely different objects?

As I already said programs in Java don't work with objects, but with references to objects. If the reference has the same name and refers to an object of the same type (that means to an instance of the same class), the program doesn't notice any change and will speak with the reference in an unchanged way without regard to a possible change of the referred object.

The references now points to other objects, but we let them the same names. The test methods therefore don't notice that anything has changed and will run with new fixture without talkback. Only we know that they send their messages through the same references but to other objects because our references now refer to them.

Let me try to get it through to you with an example from life. Imagine that you are a boss of a department with employees working somewhere in the world. You communicate with them through e#8209;mail. The employees are objects and their e#8209;mail addresses are the names of reference to each of them.

When an employee (object) asks somebody else (another object) to stand in for him/her and this person starts to answer your messages (that means when your reference starts to refer to somebody else) they will react to your messages instead of the original object, you are not able to detect it until the new object somehow reveals this fact to you.

Parameters of object types

I understand. When we came to objects – you said that we work with objects in another way than with values of primitive types. Is it true for parameters, too?

Certainly, if you need to assign a primitive value to a message parameter you simply get the value and assign it. If you work in the interactive mode of BlueJ, as we are currently, you simply write this value into the corresponding input text field.

With object values it is a little more complicated. Instead of them you assign to parameters the references to these objects through which the addressed object communicates with them.

You can get the reference to an object only in such a way that you send a message to an object, which can return requested reference.

There is only one exception: the texts. If you write a text closed in double quotes, you create an object representing this text in program. In addition this object belongs to a group of objects with special features which allow you to work with these objects in a similar way as with values of primitive types. We will talk about it in more detail in future.

It will be best if you show me it again in some example.

Alright, we start with improving the test fixture. I have to say that I don't like that after running the test we see immediately the result and that we cannot compare it with the original state. We rectify it and by the way learn how to work with text strings.

We utilize the service of class IO (the name IO comes from Input/Output), that can on demand open a dialog box with given message and freezes the running program until the user confirms reading of the message.

Reset the virtual machine, ask the class Test for our favorite test fixture and send to class IO the message

void inform(Object text)

BlueJ opens a dialog box asking for the object (better for the reference to object), which we want to set as the parameter of this message. This parameter is an instance of class String. Fortunately this class allows writing the values of its instances directly. As we said in the previous lesson in part How to write strings, we must close the text representing values of instances of class String inside quotation marks. Enter e.g. text (don't forget write also the quotation marks):

"Fixture prepared"

Figure 3: We send the message IO.inform("Fixture prepared") to class IO

The class answers by opening a dialog box with the given text:

Figure 4: Advice about preparing of the fixture

Now ask BlueJ to create a new version of the program preparing the test fixture for class Test (the test fixture itself didn't change, we only added an appended action) and confirm that the original fixture should be replaced (more exactly that it should replace the original program creating the fixture).

Next try to load the test fixture and verify that it includes the opening of the demanded dialog box with the message announcing the preparedness of the test fixture. At the end run one of the two prepared tests to see how the opening of the dialog box and associated freezing of the program make the action with the fixture more visible.

To facilitate eventual revision in the future I have again prepared a small accompanying animation that shows the just described actions. If you have any problem with performing these actions, run the animation and try to follow everything in the shown (demonstrated?) way.

Click here to run annimation

Animation 1: Messages with parameters

Revision

Revise once more what we have learned today:

  • Parameters allow us to precisely specify what we want to get by sending the given message; e.g. when creating shapes we can tell the position, the size and the color (precisely NamedColor) of the created object.
  • In the interactive mode we set the parameter values in the text fields of the dialog box opened by BlueJ after entering a command asking for a message with parameters to send.
  • If we ask the test class with test fixture to save another test fixture (precisely the program preparing the test fixture), BlueJ first asks, if we really want to replace the old program by the new one, and after confirmation of our demand it replaces the program.
  • Again we must remember that in Java we never work direct with objects; however we work only with references to objects.
  • When we change the content of the reference, the program working with this reference will send messages to the newly referenced objects.

Note:
You can download the current version of the project here.

Contents of whole series

Rudolf Pecinovsky
(rudolf.pecinovsky@i.cz) is a senior EDU expert in ICZ, Inc. and associate professor of software engineering at The University of Economics, Prague. He has more than 20 years experience in programming education. Rudolf published 39 books in five national languages. His latest book on design patterns was launched in September 2007.

Project Features

Project Links

About this Project

edu was started in November 2009, is owned by Antonin Nebuzelsky, and has 87 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close