\section{Object-Oriented Programming}:

Object-oriented software is all about objects. An object is a "black
box" which receives and sends messages. A black box actually contains
code (sequences of computer instructions) and data (information which
the instructions operates on). Traditionally, code and data have been
kept apart. For example, in the C language, units of code are called
functions, while units of data are called structures. Functions and
structures are not formally connected in C. A C function can operate on
more than one type of structure, and more than one function can operate
on the same structure.

Not so for object-oriented software! In o-o (object-oriented)
programming, code and data are merged into a single indivisible thing --
an object. This has some big advantages, as you'll see in a moment. But
first, here is why SDC developed the "black box" metaphor for an object.
A primary rule of object-oriented programming is this: as the user of an
object, you should never need to peek inside the box!

Why shouldn't you need to look inside an object? For one thing, all communication to it is done via messages. The object which a message is sent to is called the receiver of the message. Messages define the interface to the object. Everything an object can do is
represented by its message interface. So you shouldn't have to know anything about what is in the black box in order to use it.



And not looking inside the object's black box doesn't tempt you to directly modify that object. If you did, you would be tampering with the details of how the object works. Suppose the person who programmed the object in the first place decided later on to change some
of these details? Then you would be in trouble. Your software would no longer work correctly! But so long as you just deal with objects as black boxes via their messages, the software is guaranteed to work. Providing access to an object only through its messages,
while keeping the details private is called information hiding. An equivalent buzzword is encapsulation. 

Why all this concern for being able to change software? Because experience has taught us that software changes. A popular adage is that "software is not written, it is re-written". And some of the costliest mistakes in computer history have come from software that
breaks when someone tries to change it. 

Classes

How are objects defined? An object is defined via its class, which determines everything about an object. Objects are individual instances of a class. For example, you may create an object call Spot from class Dog. The Dog class defines what it is to be a Dog
object, and all the "dog-related" messages a Dog object can act upon. All object-oriented languages have some means, usually called a factory, to "manufacture" object instances from a class definition. 



                                                                   Spot

You can make more than one object of this class, and call them Spot, Fido, Rover, etc. The Dog class defines messages that the Dog objects understand, such as "bark", "fetch", and "roll-over". 

You may also hear the term method used. A method is simply the action that a message carries out. It is the code, which gets executed when the message is sent to a particular object. 

Arguments are often supplied as part of a message. For example, the "fetch" message might contain an argument that says what to fetch, like "the-stick". Or the "roll-over" message could contain one argument to say how fast, and a second argument to say how many
times. 
