|
Chapter: Object
Oriented Programming
The Blueprint Analogy
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.
A single
blueprint could be used to make several derivatives
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.
|
|
Previous
