> > OO. The defining, mandatory elements of the object model are:
> >    Abstraction
> >    Encapsulation
> >    Modularity
> >    Hierarchy
>
> Not to pick nits (really!), but I believe the four are:
>
>      Abstraction
>      Encapsulation
>      Polymorphism
>      Inheritance
>
> I can see how "hierarchy" could be used for "inheritance," but I fail
> to see how "modularity" differs from "encapsulation;" it  seems the former
> would be a subset of the latter.  This explains why I don't
> see anything like polymorphism in the first list.

It probably depends on who you read. My list is from section 2.2 of Booch's
"Object Oriented Design with Applications", 2nd Ed. As you suggest,
Inheritance is one form of Hierarchy; Aggregation, indicating a "part of"
hierarchical structure instead of "is a subtype of", is another.
Polymorphism is a method of typing, which Booch lists as one of the minor
elements of the object model. As for encapsulation and modularity, he
defines them as follows:
 Encapsulation is the process of compartmentalizing the elements of an
abstraction that constitute its structure and behavior; encapsulation serves
to separate the contractual interface of an abstraction and its
implementation.
 Modularity is the property of a system that has been decomposed into a set
of cohesive and loosely coupled modules.

IOW, modularity achieves Wirt's pleiotropy-reduction goal, so changing one
component doesn't break a lot of others, while encapsulation decouples the
externally-visible interface of each component from its internal states and
operations, so you can change how a given interface-exposed operation is
achieved without breaking the contract. To highlight the difference, you
could create a highly modular system that has little encapsulation; for
example, a class representing a "file" abstraction that exposes the
file-position pointer, data buffer, raw file-system attributes and flags,
and other should-be-internal stuff in its interface. All file-related
operations are handled exclusively by this class, so the system is
completely modular, at least as far as file operations are concerned.
However, by not encapsulating the raw attributes and operations, you make it
difficult or impossible to change the implementation of the file object (for
example, to "read" and "write" data from/to a network connection instead of
a storage-system device, or even to switch from a random-access device like
a disk to a serial-access device like a tape) without breaking the
contracted interface with the clients of the file class.

For completeness, here are Booch's definitions of some of the terms of
interest in this discussion:
 Object-oriented Programming--a method of implementation in which programs
are organized as cooperative collections of objects, each of which
represents an instance of some class, and whose classes are all members of a
hierarchy of classes united via inheritance relationships.
 Object-oriented Design--a method of design encompassing the process of
object-oriented decomposition and a notation for depicting both logical and
physical as well as static and dynamic models of the system under design.
 Object-oriented Analysis--a method of analysis that examines requirements
from the perspective of the classes and objects found in the vocabulary of
the problem domain.

His full definition, discussion, and examples of these concepts goes on for
over fifty pages, so I won't quote it in its entirety ;-) But it's worth a
read if you're interested in the subject matter.