0.1 Pr0110-anatomy of the processing framework  (Page 4/10)

Inherited methods

We can see from Listing 2 that our new class inherits a method named setup , a method named draw , and a method named size . The code in Listing 2 overrides the setup and draw methods and calls the size method without overriding it.

The class named PApplet defines a huge number of methods. Those methods can be called from within our class named Cars (by novice programmers) without knowledge of anything related to object-oriented programming. They look pretty-much like global function callsfrom the dark ages.

A function library

In effect, the authors of Processing have created a huge function library, (reminiscent of the function libraries of the dark ages of Pascal and C) . Novice programmers can use that library to create sketches using a proceduralprogramming style (as opposed to an object-oriented programming style) ..

A tricycle and a bicycle

While I don't think this is a good way to teach people how to program, I am impressed that the authors of Processing were able to pull it off.

In my opinion, learning to program this way is like trying to learn how to ride a bicycle by riding a tricycle. (I'm not talking about a bicycle with removable training wheels. I'm talking about a vehicle with three fixed wheels.)

As long as that tricycle (the PDE) will get you where you need to go, everything is okay. However, without specialeffort on your part, you will be ill-equipped to put the PDE aside and ride the bicycle (write object-oriented code ) if this is how you learn to program.

Understanding the anatomy of the framework

That having been said, by understanding the anatomy of the framework, it is possible for novices and experienced programmers alike

• to think in object-oriented terms,
• to write serious object-oriented programs using the PDE, and
• to take advantage of the many libraries supported by Processing.

The ability to effectively use multiple libraries is one of the hallmarks of a successful OO programmer.

The draw method

The description of the draw method (that is inherited from the PApplet class) reads partially as follows:

"Called directly after setup() and continuously executes the lines of code contained inside its block until the program is stopped or noLoop() is called.

The draw() function is called automatically and should never be called explicitly.

It should always be controlled with noLoop(), redraw() and loop().

After noLoop() stops the code in draw() from executing, redraw() causes the code inside draw() to execute once and loop() will cause the code inside draw() to execute continuously again.

The number of times draw() executes in each second may be controlled with frameRate() function.

There can only be one draw() function for each sketch and draw() must exist if you want the code to run continuously or to process events such as mousePressed(). Sometimes, you might have an empty call to draw() in your program ..."

Default behavior of the framework

We know that the default behavior of the framework is to display a window on the screen similar to Image 1 if we don't override the draw method.