A survey by Deborah J. Armstrong ([2] of nearly 40 years of computing literature identified a number of ‘quarks’, or fundamental concepts, found in the strong majority of definitions of OOP. They are the following:
Defines the abstract characteristics of a thing (object),
including the thing's characteristics (its attributes,
fields or properties) and the thing's behaviors (the
"things it can do", or methods, operations or
features). One might say that a class is a blueprint or
factory that describes the nature of something. For example,
the class Dog
would consist of traits shared by all dogs,
such as breed and fur color (characteristics), and the ability to bark
and sit (behaviors). Classes provide modularity and
structure in an object-oriented computer program. A class
should typically be recognizable to a non-programmer familiar with the
problem domain, meaning that the characteristics of the class should
make sense in context. Also, the code for a class should be relatively
self-contained (generally using encapsulation). Collectively,
the properties and methods defined by a class are called
members.
A particular instance of a class. The class of Dog
defines all possible dogs by listing the characteristics and behaviors
they can have; the object Lassie
is one particular dog,
with particular versions of the characteristics. A Dog
has fur; Lassie
has brown-and-white fur. In programmer
jargon, the Lassie
object is an instance of the
Dog
class. The set of values of the attributes of a
particular object is called its state. The object consists of state and the behaviour
that's defined in the object's class.
An object's abilities. Lassie
, being a
Dog
, has the ability to bark. So bark()
is
one of Lassie
's methods. She may have other methods as
well, for example sit()
or eat()
or
walk()
. Within the program, using a method usually
affects only one particular object; all Dog
s can bark,
but you need only one particular dog to do the barking.
Message passing
“The process by which an object sends data to another object or
asks the other object to invoke a method.” [2] Also known
to some programming languages as interfacing. That is, the object called
Breeder
may tell the Lassie
object to sit by
passing a 'sit' message which invokes Lassie's 'sit' method. The
syntax varies between languages, for example: [Lassie
sit]
in Objective-C. In Java code-level message passing
corresponds to "method calling".
Inheritance
‘Subclasses’ are more specialized versions of a class, which inherit attributes and behaviors from their parent classes, and can introduce their own.
For example, the class
Dog
might have sub-classes called Collie
,
Chihuahua
, and GoldenRetriever
. In this
case, Lassie
would be an instance of the
Collie
subclass. Suppose the Dog
class
defines a method called bark()
and a property called
furColor
. Each of its sub-classes (Collie
,
Chihuahua
, and GoldenRetriever
) will inherit
these members, meaning that the programmer only needs to write the
code for them once.
Collie
class might specify that
the default furColor
for a collie is brown-and-white. The
Chihuahua
subclass might specify that the
bark()
method produces a high pitch by default.
Subclasses can also add new members. The Chihuahua
subclass could add a method called tremble()
. So an
individual chihuahua instance would use a high-pitched
bark()
from the Chihuahua
subclass, which in
turn inherited the usual bark()
from Dog
.
The chihuahua object would also have the tremble()
method, but Lassie
would not, because she is a
Collie
, not a Chihuahua
. In fact,
inheritance is an ‘is-a’ relationship: Lassie
is a
Collie
. A Collie
is a
Dog
. Thus, Lassie
inherits the methods of
both Collie
s and Dog
s.Multiple inheritance is inheritance from more than
one ancestor class, neither of these ancestors being an ancestor of
the other. For example, independent classes could define
Dog
s and Cat
s, and a Chimera
object could be created from these two which inherits all the
(multiple) behavior of cats and dogs. This is not always supported, as
it can be hard both to implement and to use well.
Encapsulation conceals the functional details of a class from objects that send messages to it.
For example, the Dog
class has a bark()
method. The code for the bark()
method defines exactly
how a bark happens (e.g., by inhale()
and then
exhale()
, at a particular pitch and volume). Timmy,
Lassie
's friend, however, does not need to know exactly
how she barks. Encapsulation is achieved by specifying which classes
may use the members of an object. The result is that each object
exposes to any class a certain interface — those members
accessible to that class. The reason for encapsulation is to prevent
clients of an interface from depending on those parts of the
implementation that are likely to change in future, thereby allowing
those changes to be made more easily, that is, without changes to
clients. For example, an interface can ensure that puppies can only be
added to an object of the class Dog
by code in that
class. Members are often specified as public, protected
or private, determining whether they are available to all
classes, sub-classes or only the defining class. Some languages go
further: Java uses the default access modifier to restrict
access also to classes in the same package, C# and VB.NET reserve some
members to classes in the same assembly using keywords internal
(C#) or friend. (VB.NET), and Eiffel and C++ allows one to
specify which classes may access any member.
Abstraction is simplifying complex reality by modelling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem.
For example, Lassie
the Dog
may be
treated as a Dog
much of the time, a Collie
when necessary to access Collie
-specific attributes or
behaviors, and as an Animal
(perhaps the parent class of
Dog
) when counting Timmy's pets.
Abstraction is
also achieved through Composition. For example, a class
Car
would be made up of an Engine, Gearbox, Steering
objects, and many more components. To build the Car
class, one does not need to know how the different components work
internally, but only how to interface with them, i.e., send messages
to them, receive messages from them, and perhaps make the different
objects composing the class interact with each other.
Polymorphism allows you to treat derived class members just like
their parent class' members. More precisely, Polymorphism in
object-oriented programming is the ability of objects belonging to
different data types to respond to method calls of methods of the
same name, each one according to an appropriate type-specific
behavior. One method, or an operator such as +, -, or *, can be
abstractly applied in many different situations. If a Dog
is commanded to speak()
, this may elicit a
bark()
. However, if a Pig
is commanded to
speak()
, this may elicit an oink()
. They
both inherit speak()
from Animal
, but their
derived class methods override the methods of the parent class; this
is Overriding Polymorphism.
Overloading Polymorphism is the use of
one method signature, or one operator such as ‘+’, to perform several
different functions depending on the implementation. The ‘+’ operator,
for example, may be used to perform integer addition, float addition,
list concatenation, or string concatenation. Any two subclasses of
Number
, such as Integer
and
Double
, are expected to add together properly in an OOP
language. The language must therefore overload the concatenation
operator, ‘+’, to work this way. This helps improve code readability.
How this is implemented varies from language to language, but most OOP
languages support at least some level of overloading
polymorphism.
Many OOP languages also support Parametric Polymorphism, where code is written without mention of any specific type and thus can be used transparently with any number of new types. Pointers are an example of a simple polymorphic routine that can be used with many different types of objects.
[1] Object-Oriented Programming, Wikipedia
[2] Armstrong, Deborah J. (February 2006). "The Quarks of Object-Oriented Development". Communications of the ACM 49 (2): 123–128. ISSN 0001-0782