|
Chapter: Visual
Representations
of Code 
Drawing Irregular Shapes
Order, order!
We now have a speech bubble, but where's our text gone to? If you added
the statement to draw the irregular shape to the end of your sketch,
Processing would have drawn the speech bubble over your text. Your text
is still there just underneath the speech bubble, obviously this is not
the desired effect. So we are going to reorder things in our sketch,
with some simple cut and paste commands. Cut the three statements that
relate to rendering text to the Display Window textAlign(), textSize()
and text() to the end of the sketch so that they are run after the
speech bubble is drawn. If you were to run the sketch at this point
your text will still appear to be missing, but in fact is still there
it's just that because it's been drawn after the speech bubble it's
also been effected by the fill() function issued to change the speech
bubble's fill to white. White text on a white background isn't very
legible so we'll change the text to another color, I'm going to make my
text the same color as the speech bubble outline by adding the
following statement before the text is drawn and after the speech
bubble is rendered:
fill(50,127,255);
Finishing the sketch
To add the final touches to the Hello World 1.2 Program we're going to
get Processing to display an image for the sketches background instead
of the black background. This exercise will also be our first
introduction to the programming paradigm known as Object Oriented
Programming and the concept of data typing.
The first thing we need to do is set our sketch up to accept external
data in the form of an image. With the PDE still open, via your
computer's operating system open a file browser and locate the file
named “smileBkg.png”. From your file browser click and drag the image
file into the sketch you are currently working on in the PDE.
When you have dropped the file to the sketch Processing, will confirm
this in the debugging area by printing the phrase “One file added to
the sketch”. If you get this message you are ready to start using the
image in your sketch.
Adding an
Image to a Sketch in Processing is easy, just click and drag it into
the PDE.
The simplest way to use external data, such as an image, in your
Processing sketch is to ensure that the data exists in a folder called
“data”, which must be a subdirectory of the location where your sketch
is saved. For example, we set up Processing to store all sketches in
folder called “Sketchbook”, stored within this folder will be the
sketches we create with the PDE. I've called my Hello World 1.2 Program
“smile” so within the Sketchbook folder is another folder called
“smile” and within the smile folder is the file smile.pde (which is my
Hello World sketch) and another folder called “data”. When we dropped
the image into the PDE Processing automatically created the data
folder, and placed a copy of the smileBkg.png file in it. If you would
like to view the contents of this folder you can access it from the PDE
by clicking:
Sketch → Show Sketch Folder
Or simply navigating to the folder with your operating system's file
browser.
When transporting your Processing sketches from one computer to another
you must always retain this directory structure of having your data
folder as a subdirectory of the location where your processing sketch
resides, which should always have the extension .pde.
Programming Paradigms
A programming paradigm is a fundamental style of programming, the term
is often confused with programming methodology which is a style of
addressing a problem within a program. But perhaps a better way to
understand what a programming paradigm is, would be to look at some
examples of it.
Many modern day software languages offer at least two fundamental
programming paradigms, most commonly amongst these two choices are the
Objected Oriented Programming Model and the Procedural Programming Model
(Procedural programming is also sometimes referred to as imperative
programming). Like the name implies imperative programming is a
programing paradigm that is used to determine a set of commands and/or
steps a computer program must take in order to reach a desired state.
It's worth knowing that the Object oriented programming model is often
contrasted to the procedural programming model because of the
fundamental differences (which we are about to discuss) that separate
these programming paradigms.
Procedural Programming can be summarized as a style of programming
where the program is tailored to suite the data as opposed to Object
Oriented Programming which is more akin to a style of programming where
the data is tailored to suite the program. So what exactly does that
mean?
As mentioned earlier, programs are made up of statements and one of the
things statements are made up of, is commands. As you might recall a
command in programming, much like in a natural language, is used to
communicate a directive. In this way procedural programming is a list
of statements telling a computer what to do. At this point you could be
thinking “Isn't that the purpose of all programming i.e. telling a
computer what to do, so how then does procedural programming differ
from any other programming paradigms?”
In one way or another we use programming to represent data, whatever
that data may be the amount of tea compared to the amount of coffee
consumed over the past ten years world wide, determining the choices a
character has in a game then choosing to act on those choices or
something as simple as representing a set of alpha numeric characters
on a screen that spells your name. Whatever way you look at it creating
a program requires data. In procedural programming we use the tools
provided to us by the language we are programming in to break down that
data into smaller data types that the language predetermines for us and
then use those representations to create a program that ultimately
represents the larger original data set programmatically. This can be
contrasted to object oriented programming where we use the tools
provided to us by the language we are programming in to create our own
data types for which we determine their meanings and use these new data
types to create a program that ultimately represents our original data
set.
Either way you look at it the results of both procedural and object
oriented programming can produce software that is modular in design,
meaning that components of the data that can be represented with either
one of these paradigms can be dynamic or changing, or even completely
non-existent. Designing software that does not have to be rewritten
each time the data that it represents changes or is removed from the
main program entirely, is a challenge regardless of which programming
paradigm you might use and it is this key feature of software design
that determines how modular the main program is.
Object Oriented Programming since it's earliest inceptions in the late
1950's programming language LISP has consistently seen various
implementations on the concept of modularity amongst other features
such as encapsulation (which we will discuss in more detail later),
contributing to it's modern day popularity. As software development
needs have become more demanding and larger data structures are
required for abstractions, Object Oriented Programming due to it's
inherent ability to represent complex data structures, modularly has
grown in popularity to meet the needs of software developers creating
these sophisticated programs. That is however not to say that
procedural programming lacks sophistication. To summarize programming
paradigms in a utilitarian sense, people tend to address problems in
different ways, programming paradigms accommodate for these shifts in
thought and conceptualization.
|
|
Previous