An object is "anything with a boundary." This can be extended in computer science to be "anything with a boundary that represents a uniquely identifiable entity; unit; or item, real or abstract; that represents some element in the problem domain."
What this means is that an object represents a "thing" or an idea in the real world. Although programmers talk of objects in non-object orientated languages like C, this is a bit misleading because in Object Orientated Design objects typically have both data, sometimes called "state" or "identity," and they have behavior, things that they can do, either on their own data or data given to them by other objects. The behaviour of objects is defined by the methods it supports. A method is basically a function, or self-contained block of code that performs some action and returns a value. The semantic difference between methods and functions is merely that a method always belongs to an object, whereas a function can be "global" in the sense that it belongs to the program as a whole or to a code module. C++ supports conventional functions and methods, but in Java, every function is a method.
Typically, an object will be of a certain type or "class." If an object is a thing, then a class is a description or blueprint for what that thing looks like, what is in it, and what it can do. Special methods declared for the class construct instances of the class - objects - from the raw bits and bytes of computer memory. These special methods are called "constructors," for obvious reasons.
It is this distinction that draws the line between genuine objects as instance of classes and loose collections of data like C and C++ structures and Pascal records. Objects are living, breathing entities in a program that can do things of their own accord in response to stimuli; structures and records are dull, lifeless things that are manipulated by external functions and procedures. Objects do; structures are done to.
Objects are strongly tied up with the idea of encapsulation, which, in computer science is broadly the practice of bringing together elements to produce a new entity. In the more specific case of object-orientated programming, encapsulation implies data hiding and the abstraction of behaviour from implementation: if the internal data and workings of the object are encapsulated, then objects have to interact through a set of clearly defined interfaces. These interfaces are represented by the class methods or member functions. By invoking a method on an object, the programmer sends the object a message that tells it to do something or send back some data. Object-oriented programs are defined as sequences of interactions between objects. Objects maintain their own state and identity and have clearly defined responsibilities in terms of the behavioural contract they make with other objects in the program.
Object-orientated languages like C++ and Java rely heavily on encapsulation to create classes and objects as instances of those classes. Both of these languages contain keywords like "public," "private" and "protected" that force the compiler to enforce rigidly the encapsulation of both data and functionality; encapsulating data in this way is called "data hiding."
Classes have "visibility modifiers" that the compiler enforces to say what external entities can see in an object. A "public" item, whether it is a member variable or method, is in C++ and Java is visible to anyone and everyone. A "protected" item in C++ is visible only to objects of that specific type or objects of classes derived from that type; in Java a "protected" member is visible only to objects of its own class, objects of subclasses, or within classes in the same package, where a package is a logical collection of classes that have some (possibly) arbitrary common attributes. In both C++ and Java, "private" member items are visible only to the class they are defined in. These visibility modifiers enforce encapsulation and facilitate data hiding.
Data hiding is where the details of an object or function are invisible to the outside world. The data can be accessed via methods that are privileged to see them, the "accessor methods," but they are not immediately visible in themselves. If the data are to be changed in some way, say because of external events, the program sends a message to the object by invoking a method, or function owned by the object, and that makes the change to the encapsulated data. Functions that change the internal state of an object are called "mutators." Methods can themselves be encapsulated, which means they may be accessible only from within the object itself. Methods that are encapsulated are typically those that would reveal details of the object's implementation to the outside world.
It is also possible to use a class as the basis for deriving another class. This is called "subclassing" and the derived class is called a "subclass" or a "derived class." The class the subclass is based on is called the "base class," or the "superclass," or, in some circles, the "parent class." The base class is related to the subclass in a "kind of" relationship where the subclass is a "kind of" the base class. For example, a PlymouthFury might be derived from a Car class, and it is clear that a Plymouth Fury is a "kind of" car, and not the other way around.
Properly designed and implemented object oriented programs tend to be less complex and hence more easily written and maintained than their non-object orientated counterparts. Specifying program behaviour in terms of object interfaces and hiding the details of implementation from the users of the objects means that the effects of code changes is minimised, thus reinforcing the principle of less complex and hence more reliable code.
This is the complete article, containing 952 words
(approx. 3 pages at 300 words per page).
