An Introduction To Programming With Processing

The Blueprint Analogy

Derivitives from the same Blueprint
By creating classes we categorize the data we are representing and give these representations a context by associating them with features in the programming languages API. However a class is never used in the main program, it must first be instantiated as an object and the object is what we would use in our main program. In this sense a class is more like a blueprint, that describes the complex relationships between the data we are representing, like the blueprint of a house can describe how tall a wall will be or how far a window will be from the ceiling. If you can imagine a class to be like a blueprint then a software object is like a house made from that blueprint. For example, a class only describes the possible objects that can be instantiated from it, taking the blueprint analogy further we cannot live in a blueprint yet it has all the information we need to build a house which would be something that we use as a functional object. In other words we use the blueprint to build a house, this is just like instantiating an object from a class. The class only describes the possibilities of an object that can be instantiated from it and when we finally do instantiate an object from the class, it is the object that we use in our main program. Just like a blueprint describes a structure it does not say anything about how the structure can be used for example a blueprint can be used to build somebody's home or the same blueprint can be used to build an office. The purposes the buildings serve are different, but the structure of the buildings remains the same. The relationship between classes and software objects is very similar, in that one object instantiated from class can serve a certain purpose and another object instantiated from the same class can serve a different purpose, but because both objects are instantiated from the same class the context in which they are used will tend to have similarities.

Why use Object Oriented Programming

One of the fundamental concepts that makes OOP so popular is known as data encapsulation. We have already discussed how a variable can have a greater or lesser scope depending on where it is declared, that is to say that when a variable is not declared within the global variable scope it can only be accessed in some parts of a program and not in others that are outside of the structure in which it was declared. The range over which the variable is accessible refers to the variable's scope. Data encapsulation is a similar concept, except that the concept of “hiding” data is emphasized as opposed to defining a variable in the global variable scope where the concept of “exposing” data is emphasized. Another major difference between the two concepts is that with data encapsulation as opposed to variable scope we are not referring to a single variable but can, in fact, be referring to entire structures. These structures that we make inaccessible to the main program are what form the body of code that defines a class. By defining a class we use a modular approach to designing software, in the sense that the class that we have defined is not necessarily specific to the program we initially wrote it for, and as a result can be used in our program or removed from our program without us having to rewrite the entire program this is an inherent design characteristic of data encapsulation. Amongst other applications, creating a class defines the behaviors that an object instantiated from it will inherit. In order to interact with an object in a program, and subsequently use that which it has inherited from a class, we interact with the object via it's behaviors which are more commonly referred to as methods. This is a form of data encapsulation, in that we do not have direct access to how that object works as that is defined within the class. However we can still have the object interact with our main program through it's methods. In this sense Object Oriented Programming can provide a level of abstraction, when working with objects in the main program.