2 Introduction

Rudolf Pecinovsky

Contents of whole series

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

Objects, classes and their instances

I have learned opening and closing projects together with manipulations with classes (better to say the rectangles representing them). I think you should now explain what the classes are for.

Be patient, I come to the explanation by a detour. Object oriented programming is built on the realization that every program is a simulation of a real or a virtual world.

  • A bookkeeping program simulates the behavior of a company and their customers referring to orders, deliveries, invoices and payments. It synchronizes its function with reality by drawing invoices, registering payments and similar activities.
  • A chess program simulates the actions in a virtual chess world where two armies attack each other; one of them being directed by the player and the other by the computer.
  • A drawing program simulates the actions in a virtual world of geometrical shapes which interact in various ways.

And so we could continue program by program.

Each world consists of objects. If the program should simulate the actions in this world, it has to be able to work with objects.

In real life we are willing to take as objects persons, animals and things. However, OOP generalizes this understanding and takes as objects also properties (colors, aromas '), events (connection, interrupt '), states (quiet, movement ') and generally everything that we name with a noun.

In larger programs there are thousand and tens of thousands of objects. If we want to effectively work with them, we have to sort them. If you have all your papers on your table in one heap, you can't work well with them. You will probably first arrange the papers into some thematic groups.

We work in a similar way with objects. We assign them to classes which associate all objects with some particular properties declared by their class. Objects belonging to a particular class we term instances of their class. E.g. my computer as well as your computer belongs in the generalized class of desktop computers.

What is the difference between an object and an instance?

There is almost no difference. They are synonyms. We prefer the term object in situations, when we talk about a general object and we prefer the term instance when we want to emphasize that the object belongs to particular class (the object is an instance of class XYZ).

You have said that everything that we can label with a noun is an object. In such a case the class should be an object, too.

You are right. The class is an object, which keeps all information characterizing its instances. However don't be disturbed by this marginal problem. When you get some experience, you will take it as absolutely normal.

It is too abstract for me. Can you explain it with some example?

I'll try. A while ago I said that my computer and your computer are instances of the class of all computers. Similarly the table, on which the computer stands, is an instance of the class of all tables and the chair you are sitting on is an instance of the class of all chairs.

A class can create its instances. We can take it as a factory for its instances. In a program if you need a new computer, you ask the computer class for its new instance and if it is be possible, the class will create the asked instance and give it to you. If you need a new car, you ask the class of cars and it will create a new car for you.


What a pity that it is not so simple in real life. But how does the asked class recognize what kind of computer or car I want?

You send your request as a message. This message can contain detailed specification of your request. We then say that you send a message with parameters or arguments.

Well. I have asked the car class for a car and I have got one. But how do I get somewhere with this car in the program?

You continue in the same way: your object sends to the car's object a message that it should go to the requested place. Well, it may be useful to get into it first. The resulting program can be:

car open
car getIn me
car close
car go target

I see that the car can open and close itself. With an ordinary car I have to open it and close it. And the getting in I do not understand at all. Why have I to say to the car that I am getting in?

The car is not closing itself, it is closing in reaction to your message. In the real word you send the message by taking the handle or pushing the door. In the virtual word of computer program you send the message in another way, however the result is the same: the door opens or closes.

Maybe. But why I have to tell the car that I am getting in and why cannot I simply get in without talking about it.

Because the computer program has not the omnipresent physics, that tells the car everything independently of you. In the real word when you get in, you put in the car your xyz kg (or lb) of your mass and the car immediately knows, that you are in. In a computer program the programmer has to stand in for physics and explicitly give to the object the needed information.

It looks that a program is nothing else than a permanent sending of messages from one object to another.

Exactly. The classical, structured program is sometimes defined as the sequence of statements describing how to solve a particular problem. The object oriented program, on the other hand, we can define as a set of objects and messages, which these objects send one to another.

The different nature of each type of program necessarily leads to different approaches to analysis of the problem and the following design of the program. Let's have a look at an existing program and try to play with it for a while.

The First Project

What about stopping with the theory and starting to try some real example.

I agree. Unlike common methods we will not create some Hello Word program – we leave it to textbooks that try to teach syntax. We want to concentrate on programming and therefore we will from the very beginning use non-trivial projects.

Do you think that it is reasonable to begin with the – as you say – non-trivial projects although I know almost nothing about programming?

Don't worry. These projects will be sufficiently simple for beginners to understand their architecture, but on the other hand they will be sufficiently complex to allow you to learn about working with objects as much a possible.

We start with the project 01_Shapes working with geometrical shapes, which we used when you came acquainted with BlueJ and learned how to manipulate classes in a class diagram. Open it to allow me to give you some other information about BlueJ class diagrams.

I have opened it. What do you tell me about it?

Figure 1: BlueJ application window with opened project 01_Shapes

As we already said, each rectangle represents a class. In the shown project there are seven classes:

  • Instances of classes Ellipse, Rectangle and Triangle represent corresponding geometrical shapes.
  • The instance of class Canvas represents a canvas on which all geometrical shapes will be painted. This class has to guarantee that it will have only one instance. So it will ensure that all shapes are painted on the same canvas.
  • The instances of class NamedColor represent colors of the canvas and painted shapes.
  • The instances of class Direction8 represent eight cardinal and intercardinal directions; they are directions to which the triangle can be turned.
  • The class IO has no instance. The reason for its incorporation into the project was to add the ability to send messages to the user or to ask them for something through dialog box. In addition it is able to freeze the program for given amount of time.

Why has the class Direction8 another color to all the other classes?

This class has some special features and therefore it is appropriate that it looks different. Down the road, when your knowledge is greater, I will explain them to you. Now would be too soon.

Why are there the arrows?

The arrows mark dependences between classes. E.g. the arrow going from class Canvas to class NamedColor tells that the class Canvas depends on the class NamedColor, because it is not possible to create a canvas, which doesn't have any color.

The shapes classes are dependent on NamedColor, too, because they also should be painted in some color. In addition they are dependent on class Canvas, because it is the only place, where they can be painted.

So we have made everything clear and we can start to program.

Wait a while yet. To start programming you need some basic knowledge. Therefore we will first play with our classes and their instances to understand how the object oriented program works. Then we will get down to real programming.

I am not crazy about it. Why do you think that playing with classes and objects can help me in my future programming?

We will play that we are a part of the program – an object that sends messages to other objects. Let's explain why other objects react to our messages in the observed way. We show how our messages should look to cause the desired reaction by the objects, to which these messages are sent.


Well, so how should I send a message to somebody?

To be able sending messages to particular parts of a program, we need the program to be running. To achieve this, we need to compile it first. Compilation translates the program from a form understandable to humans into a form which the computer can quickly process. As a class is compiled, the BlueJ is willing to mediate our communication with it.

How do I get to know that a class is compiled?

Simple. The classes, which are not yet compiled, have the bottom part of their rectangle in the class diagram hatched. After compilation the hatching disappears.

I suppose that I run the compilation by pressing the button Compile at the button pane.

Right, it is one of possibilities. Before you run it I would like to point to one feature. BlueJ first internally orders the classes according their dependences to ensure that no class is compiled until all classes, on which it depends, are compiled. You can guess the compilation order according to the arrows. The classes to which arrows lead should be compiled before the classes where these arrows begin.

The compilation process is indicated by the changed color of the class being compiled. When the class has been compiled, its rectangle gets again its original color and the hatching disappears. You can see it again in the appending animation.

Click here to run annimation

Animation 1: Compilation in BlueJ


Repeat once more, what we have came to know today:

  • For object oriented programming we use the shortcut OOP.
  • OOP is built on the realization that every program is a simulation of a real or a virtual world.
  • The real as well as virtual word a build from objects, which interacts. The programming languages should be able to describe these objects and their interactions.
  • The object interactions from the simulated world are incorporated into program as messages, which objects send one to another.
  • The object oriented program, we can define as a set of objects and messages, which the objects send one to another.
  • In OOP we take as object everything that we name with a noun.
  • The rectangles in the class diagram represent the classes in the project.
  • The arrows drawn between classes indicate dependences. The class, where the arrow starts, is dependent on the class, to which the arrow points.
  • Hatching of the bottom part of the class rectangle symbolizes that the relevant class is not compiled.
  • We can ask for compilation of all classes in the project by pressing the button Compile in the button pane. BlueJ then compiles the classes so that each class is compiled after all classes, which this class depends on.

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
Please Confirm