In the previous episodes, we have seen that the attributes

defined within the class represent informations

specific to each instance of the class.

Let us go back to our little example of the rectangle.

Each instance of rectangle, each Rectangle-type object

will have its own width, its own height.

Those are specific informations characterizing each rectangle.

Now, what does happen if several instances of a same class

need to access a same information,

a common information?

This is the object of today's episode.

In order to illustrate the problem we are interested in,

let us go back to our example of counting instances.

We have already had the chance to study it in the episodes

regarding the construction/destruction of an object.

Our goal is to account for all the instances existing

at a given time in a program.

For that, we need to have a memory area

accessible by every instance.

It will be incremented whenever an instance is created

and decremented every time an instance is destroyed.

When we had discussed this problem for the first time,

the only way we had to define this memory area,

acessible by every instance

in order to be incremented and decremented was to use a global variable.

Formerly, we were not plainly satisfied

with this declaration of a global variable.

Indeed, using global variables tends to be nefarious

in a program; it is a very poor solution.

A global variable, such as this one,

is not attached to any entity in the program.

Therefore, violates the principle of encapsulation

and is a sign of a poor modularization.

Moreover, this can induce harmful side effects.

Indeed, such a variable can be accessed

pretty much everywhere in the program, without any control.

Therefore, we should avoid this at all cost.

Alternatively, defining the counter as an attribute of the rectangle class

is clearly not a good solution either

since it would mean that each instance of rectangle

has its own counter. This is clearly not what we wish.

We wish to have a common area accessible by every instance.

Therefore, this solution is not good either.

The solution to this problem is to define the information we wish to be

common to all instances of the class

as a class attribute.

Unlike the attributes relative to instances

(the ones we were used to define up until now)

a class attribute is an attribute defined

inside the class, but matched with the reserved keyword "static".

Typically, let us us imagine a

program where severall Rectangle instances coexist.

To make things easier, there will be two.

The situation in the memory is the following.

The "r1" object has its own

specific values

for its instance attributes : the height and the width.

The same goes for the "r2" object,

having its own values

for the height and the width.

On the other hand, the class attribute "compteur" (TN: means "counter")

is a unique memory area

accessible by all the instances.

However, it only exists once in the memory.

By the way, please note that the visibility rules for a "static" attribute

are the sames as the non "static" attributes.

This means that this memory area

is accessible even if no instance has been created,

simply through the name of the class.

Very concretely, let us have a program where we declare a "Rectangle" class,

like this, with a class attribute.

We can access this class attribute without having previously

created any instance of Rectangle.

This can be done through the following notation, this one :

We are accessing the variable of the "Rectangle" class

called "compteur". We are doing this through the scope resolution operator.

To sum up, in order to define a class attribute,

we define an attribute and precede its declaration

with the reserved keyword "static".

We have seen that a class attribute is shared by all the instances.

It is a unique memory area shared by all the instances.

This memory area exists even when we have not created

any instance of this class.

We have seen we can access it

through this notation.

Also, a class attribute can,

like an instance attribute,

be either private or public.

The instance attributes are typically initialized

upon the objects' initialization.

However, we have seen that a class attribute may exist independently

from any object's construction.

In that case, how should we proceed to initialize a class attribute?

To that end, we must resort to a particular syntax.

Outside the class, we place an initialization line

with this syntax. It means :

the "compteur" variable, of the "Rectangle" class,

of the integer type,

will be initialized to 0.

Such a line of code will appear

outside the "Rectangle" class.

For example, like this.

We will take this line outside the declaration of the "Rectangle" class.

We resort to a particular syntax

since a class attribute exists even if we have not declared any instance of this class.

This means we cannot have, for example, a constructor

be in charge of the required initialization.

Resorting to a class variable in order to account

for all the instances of a class

is naturally a relatively atypical example.

Of course, there are many other situations

where it is useful to share informations between several instances.

However, most of the time, it will be a constant.

Let us take an example.

This time, we will move away from our rectangle example

and imagine a situation where we need to

reperesent the employees of a company.

This is more of an administrative example.

Let us say that an employee is characterized by an age,

the in-service date.

Also, let us say that there is an information common

to all employees. This would be the official pensionable age.

Where should we place this information on the pensionable age

(for example 65 years) ?

This pensionable age of 65 years is the same

for all employees.

Let us imagine we start by declaring it

like an instance attribute,

like this.

This means that, every time we create an employee,

this employee will have an age (30 years old)

an in-service date,

and an official pensionable age (65 years).

Same thing for the second employee, still with 65 years.

And this as many times

as there are employees,

with the value 65 repeated every time.

This information is thus uselessly repeated for each employee.

There is thus code duplication;

this could induce maintenance troubles.

For example, let us imagine that, through a change of law,

the pensionable age is changed to 67 years.

We would thus need to dive into each instance

and modify this value everywhere.

Obviously, this may beget severe maintenance problems.

The solution is obviously to define this information

as a class variable

thanks to the reserved "keyword" static.

Typically, here, "age_retraite" (TN: means "pensionable_age")

would be a memory area

commonly accessible by all the instances.

However, it will not be duplicated in each of the instances.

Typically, this will disapear.

The same goes for each instance.

To sum up, we have seen, through the previous examples

that the class attributes are typically very practical

and useful when different objects (such as our employees)

need to access a common information (such as the official pensionable age).

We have seen it lets us avoid information duplication

and permits for a better maintenance of this information.

Also, please remember the case we had studied before,

regarding instance counting.

Here, the class variable was defined as a non-constance

since we need to

decrement/increment this value every time an object is created is destroyed.

Why, this situation is rather atypical.

Practically, most of the class variables

you will encounter will be used to represent constants useful for

all the instances of a given class.

Now, you know what a class attribute is,

a "static" attribute.

Is it possible to do the same thing with methods?

The answer is yes, and we will present it for the sake of completeness,

even though "static" methods are not used very frequently.

Also, it is not recommanded to use them in object-oriented programming.

A "static" method is simply

a method defined inside a class.

This declaration is preceded with the reserved keyword "static".

In order to call an instance method, that is, the the methods we were used

to work with until now,

we forced to have previously created an object.

Only then could we call the method on this object.

For example, in order to calculate the surface of a rectangle,

we first need to create a Rectangle-type object.

Only then can we call the calculation of this rectangle's surface.

On the other hand, a class method may very well be called

if not object of the class has been

previously declared.

For example, let " A " be a class with a static method

called "methode1". We may call this method

thanks to the scope resolution operator

without having previously declared any A-type object.

Here, we simply say

that we are calling "method1" of the class "A".

Of course, such an instruction is not valid for non-static methods.

For example, here, in the class "A",

we have a second method : "methode2".

It has not been declared as "static".

If we try to call it only through the name of the class,

without passing by the creation of an instance,

we will get an error.

In order to call the non-static "methode2",

we need an previously declared A-type object

on which to call "methode2".

This is what we are doing here to calculate the surface

of a given rectangle "r".

By the way, please note

that a "static" method method may be called

either through the name of the class

(independently of the any instance's creation,

as we have done here)

or it can be called through an instance

(if such an instance exists).

Therefore, such an instruction is valid

albeit not frequent or recommanded.

Finally, this kind of instruction, accessing a "static" member

through an instance is also possible

for the attributes (if this attribute is accessible, of course).

The fact that a class method may be called independently

of the creation of any instance

begets a few restrictions regarding what we may do within

such a method.

Indeed, since a class method cannot presuppose the existence

of the current object on which it is applied,

it cannot itself use

a method or attribute presupposing the existence of an object.

It will not be able to use an instance method or attribute.

In other words, this means that a class method

can only access otehr class methods and attributes.

A "static" method can itself only use "static" members.

We may see class methods

as simple usual functions that have been placed inside a class.

In languages such as C++, where there is a non-object layer

where we can use usual functions

without passing by the creation of classes,

the use of class methods is warranted only

in very particular situations.

We can imagine, as an example,

the need to create a class method

in order to print a few values of class attributes.

We can imagine the need to define a class method

in order to manipulate class attributes, "static" attributes

who are non constant and private.

In this case, it is necessary to define such methods.

In general, it is almost always preferable to use

usual functions in C++

rather than class methods.

Above, we should absolutely avoid to have "statics" grow rampant

in a program.

Whyso?

Indeed, since a "static" member can be called independently of the creation

of any object, it weakens our oriented-object approach.

Voilà, this concludes our presentation on "static" members

in a class; methods and attributes both.

We have seen that, practically,

most of the "static" attributes we will encounter will be constants.

Also, we should remain careful not to overuse "statics".

Variables et méthodes de classe

Introduction à la programmation orientée objet (en C++)

Conheça os instrutores