[7] Classes and objects, C++ FAQ Lite







[7] Classes and objects
(Part of C++ FAQ Lite, Copyright © 1991-98, Marshall Cline, [e-mail])

FAQs in section [7]:

[7.1] What is a class?
[7.2] What is an object?
[7.3] When is an interface "good"?
[7.4] What is encapsulation?
[7.5] How does C++ help with the tradeoff of safety vs.
usability?
[7.6] How can I prevent other programmers from
violating encapsulation by seeing the private parts of my class?
[7.7] Is Encapsulation a Security device?
[7.8] What's the difference between the keywords struct and
class?



[7.1] What is a class?
The fundamental building block of OO software.
A class defines a data type, much like a struct would be in C. In a
computer science sense, a type consists of both a set of states and a
set of operations which transition between those states. Thus int is a type
because it has both a set of states and it has operations like i + j or i++, etc. In exactly the same way, a class provides a set
of (usually public:) operations, and a set of (usually non-public:) data
bits representing the abstract values that instances of the type can have.
Think of int as a class that has member functions called operator++, etc.
Note: a C programmer can think of a class as a C struct whose members
default to private. But if that's all you think of a class, then you
probably need to experience a personal paradigm shift.
[ Top | Bottom | Previous section | Next section ]


[7.2] What is an object?
A region of storage with associated semantics.
After the declaration int i; we say that "i is an object of type int."
In OO/C++, "object" usually means "an instance of a class." Thus a class
defines the behavior of possibly many objects (instances).
[ Top | Bottom | Previous section | Next section ]


[7.3] When is an interface "good"?
When it provides a simplified view of a chunk of software, and it is
expressed in the vocabulary of a user (where a "chunk" is normally a
class or a tight group of classes, and a "user"
is another developer rather than the ultimate customer).

The "simplified view" means unnecessary details are intentionally
hidden. This reduces the user's defect-rate.
The "vocabulary of users" means users don't need to learn a new set
of words and concepts. This reduces the user's learning curve.

[ Top | Bottom | Previous section | Next section ]


[7.4] What is encapsulation?
Preventing unauthorized access to some piece of information or functionality.
The key money-saving insight is to separate the volatile part of some chunk of
software from the stable part. Encapsulation puts a firewall around the chunk,
which prevents other chunks from accessing the volatile parts; other chunks can
only access the stable parts. This prevents the other chunks from breaking if
(when!) the volatile parts are changed. In context of OO software, a "chunk"
is normally a class or a tight group of classes.
The "volatile parts" are the implementation details. If the chunk is a single
class, the volatile part is normally encapsulated using the private: and/or protected: keywords. If the chunk is a
tight group of classes, encapsulation can be used
to deny access to entire classes in that group. Inheritance can also be used as a form of
encapsulation.
The "stable parts" are the interfaces. A good interface provides a
simplified view in the vocabulary of a user, and is
designed from the outside-in (here a "user"
means another developer, not the end-user who buys the completed application).
If the chunk is a single class, the interface is simply the class's public:
member functions and friend functions. If the chunk is a
tight group of classes, the interface can include
several of the classes in the chunk.
Designing a clean interface and separating
that interface from its implementation merely allows users to use
the interface. But encapsulating (putting "in a capsule") the implementation
forces users to use the interface.
[ Top | Bottom | Previous section | Next section ]


[7.5] How does C++ help with the tradeoff of safety vs.
usability?
In C, encapsulation was accomplished by making things
static in a compilation unit or module. This prevented another module from
accessing the static stuff. (By the way, that use is now depreciated: don't
do that in C++.)
Unfortunately this approach doesn't support multiple instances of the data,
since there is no direct support for making multiple instances of a module's
static data. If multiple instances were needed in C, programmers typically
used a struct. But unfortunately C structs don't support
encapsulation. This exacerbates the tradeoff between
safety (information hiding) and usability (multiple instances).
In C++, you can have both multiple instances and encapsulation via a class.
The public: part of a class contains the class's interface, which normally
consists of the class's public: member functions and its friend functions. The private: and/or
protected: parts of a class contain the class's implementation, which
is typically where the data lives.
The end result is like an "encapsulated struct." This reduces the tradeoff
between safety (information hiding) and usability (multiple instances).
[ Top | Bottom | Previous section | Next section ]


[7.6] How can I prevent other programmers from
violating encapsulation by seeing the private parts of my class?
Not worth the effort — encapsulation is for code, not people.
It doesn't violate encapsulation for a programmer to see the
private: and/or protected: parts of your class, so
long as they don't write code that somehow depends on what they saw. In other
words, encapsulation doesn't prevent people from knowing about the
inside of a class; it prevents the code they write from becoming
dependent on the insides of the class. Your company doesn't have to pay a
"maintenance cost" to maintain the gray matter between your ears; but it does
have to pay a maintenance cost to maintain the code that comes out of your
finger tips. What you know as a person doesn't increase maintenance cost,
provided the code they write depends on the interface rather than the
implementation.
Besides, this is rarely if ever a problem. I don't know any programmers who
have intentionally tried to accessed the private parts of a class. "My
recommendation in such cases would be to change the programmer, not the code"
[James Kanze, [e-mail]; used with permission].
[ Top | Bottom | Previous section | Next section ]


[7.7] Is Encapsulation a Security device?
No.
Encapsulation != security.
Encapsulation prevents mistakes, not espionage.
[ Top | Bottom | Previous section | Next section ]


[7.8] What's the difference between the keywords struct and
class?
The members and base classes of a struct are public by default, while in
class, they default to private. Note: you should make your base classes
explicitly public, private, or protected, rather than relying on
the defaults.
struct and class are otherwise functionally equivalent.
OK, enough of that squeaky clean techno talk. Emotionally, most developers
make a strong distinction between a class and a struct. A struct simply
feels like an open pile of bits with very little in the way of
encapsulation or functionality. A class feels like a living and
responsible member of society with intelligent services, a strong encapsulation
barrier, and a well defined interface. Since that's the connotation most
people already have, you should probably use the struct keyword if you have a
class that has very few methods and has public data (such things do
exist in well designed systems!), but otherwise you should probably use the
class keyword.
[ Top | Bottom | Previous section | Next section ]


 E-mail the author
[ C++ FAQ Lite
| Table of contents
| Subject index
| About the author
| ©
| Download your own copy ]
Revised May 27, 1998