Basic object orientation
History
When computer programming began in the 1930's and 1940's programs were entirely linear in nature.
A program, which was the expression of an algorithm, performed calculations that provided results based on the input conditions.
Early computers, such as the Zuse and
ACE computers had very limited storage space
and only ran a single program with repettitive loops. Complex data storage was
unheard of and even impossible because of limitations in the type and size of
random access memory available.
The notion of objects began in
the 1950's and 60's when computing systems became powerful enough to run
algorithms that worked on multiple complex data. A way to associate specific
data with the program code that manipulated it was required. From these needs
came the first principle of object orientation. Encapsulation.
Encapsulation
Data is the food and drink of
the computer. Interpreting existing data and creating new data is why the
computer exists in the first place. As the data we work with becomes more and
more complex, management of it becomes more difficult. Also, we tend to
duplicate the data in different ways. For example, creating a data object to
store simple names and adresses is a common thing to do but it may be performed
in so many different ways that it would be possible for no two programs to do it
in the same way, even different programs created by the same company.
An "object" serves the purpose
of associating a chunk of data with program code that manipulates it. In this
way, the program code, and the data structure that it uses becomes reusable. The
recreation of data to do the same job becomes less common and that object then
becomes a commodity.
Classes and Instances
The definition of an object is
called a Class. A class is an entity that knows about
a certain type of data and which contains code to manipulate that data. When we
create classes we most often give them names that mean something so perhaps a
class to store a name and address would be called PersonRecord.
Code in a class is stored in a Method. In the same way
that in your address book, you have more than one name and address, an object
that deals with names and addresses in a certain way might be duplicated n
times. One entry for each name and address. Despite the number of names and
addresses stored, the object created to deal with them would deal with them all
in a uniform manner. For example we might give the object the ability to extract
just the ZIP code from the address. For this the object might have a method
called GetZipCode. or a property called
ZipCode.
Each separate name and address
record, when in use in the program, is called an Instance
of the PersonRecord class. Its important to note that the data is
duplicated but the code is not. Each instance of the PersonRecord
object uses the same code to manipulate the data.
Members
A member is a bit of data or
code that is encapsulated by the class. A class will have two basic types of
members. Data members that are the variables which
represent the encapsulated information and Code members
which contain the program code that knows how to manipulate the encapsulated
data.
Example
Here is a class, written in C#,
that represents a person record:
class PersonRecord
{
private string
forename;
private string
surname;
private string
adress1;
private string
adress2;
private string
city;
private string
zip;
}
Notice how all of the strings that represent the data are marked as private. No
access to these variables is allowed from outside of the class.
You may think this is odd, but it's exactly as it should be. You see, a class
must always be the ultimate master of its encapsulated data. Nothing should
change that data without the knowledge of the class. All data must be
encapsulated in such a way as to protect it from changes from anywhere else.
This is a fundamental rule of object oriented architecture.
How then might a class allow data to be changed or to be read? For this, it must
provide a method.
Here are methods that get and set the Forename string:
class PersonRecord
{
private string
forename;
private string
surname;
private string
adress1;
private string
adress2;
private string
city;
private string
zip;
public string
GetForename()
{
return forename;
}
public void
SetForename(string s)
{
forename = s;
}
}
So, now, to change the forename of the person record, we must call a method to
set it. From an architecture point of view, this is good because the class now
has a little bit of code that it runs to set the internal private encapsulated
data. Why is this important? you may ask. Imagine that the class has to verify
something such as ensuring that the first character of the forename is a capital
letter. This is the place to do it. Like this perhaps:
public
void SetForename(string
s)
{
if (!char.IsLetterOrDigit(s[0])
|| char.IsDigit(s[0]) ||
char.IsLower(s[0]))
throw new
Exception("Forename
must have capital first letter");
Forename = s;
}
If you already know a little about C# you may have already spotted that the
methods used in the example could be managed via a property. You're perfectly
correct of course, but the property is nothing more than a syntactical shortcut
for the longhand methods above. Internally, a property compiles as a
get_Property and set_Property method. Here are the same members
public
string Forename
{
get { return
forename; }
set
{
if (!char.IsLetterOrDigit(value[0]) || char.IsDigit(value[0]) || char.IsLower(value[0]))
throw new
Exception("Forename
must have capital first letter");
forename = value;
}
}
Summary
In this article you've seen that an object is a self contained entity that
associates data that it encapsulates with code that
knows how to manipulate it. The object, defined by a class,
has members that provide ways to
manipulate the data. The cardinal rule of encapsulation is that direct access to
ecapsulated data must be prohibited and all manipulation of that data must be
via the member methods and properties of the class.
|