Classes in C++

Prata:

A class is a C++ vehicle for translating an abstraction to a user-defined type. It combines data representation and methods for manipulating that data into one neat package. Generally, a class specification has two parts:

• A class declaration, which describes the data component, in terms of data members (fields), and the public interface, in terms of member functions, termed methods

• The class method definitions, which describe how certain class member functions are implemented

Wikipedia: In object-oriented programming, a class is a construct that is used as a blueprint (or template) to create objects of that class. This blueprint describes the state and behavior that the objects of the class all share. An object of a given class is called an instance of the class.

Encapsulation (object-oriented programming)

From Wikipedia, the free encyclopedia

In an object-oriented programming language encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination^[1][2] thereof:

• A language mechanism for restricting access to some of the object's components.^[3][4]

• A language construct that facilitates the bundling of data with the methods operating on that data.^[5][6]

Programming language researchers and academics generally use the first meaning alone or in combination with the second as a distinguishing feature of object oriented programming. The second definition is motivated by the fact that in many OOP languages hiding of components is not automatic or can be overridden; thus information hiding is defined as a separate notion by those who prefer the second definition.

As information hiding mechanism

Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like Smalltalk and Ruby only allow access via object methods, but most others (e.g. C++ or Java) offer the programmer a degree of control over what is hidden, typically via keywords like public and private.^[4] Please note that the ISO C++ standard refers to "private" and public as "access specifiers" and they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file.

Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity and thus increases robustness, by allowing the developer to limit the interdependencies between software components.

Almost always there is a way to override such protection - usually via reflection API (Ruby, Java, C# etc.), sometimes by mechanism like name mangling (Python), or special keyword like friend in C++. This access is often necessary for debuggers, serialization, unit testing, but not uncommonly in normal code when private was overeagerly applied. [1]

This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundament of an existential type.^[7]

A common set of access specifiers that many object-oriented languages support is:

• Private (or class-private) restricts the access to the class itself. Only methods that are part of the same class can access private members.

• Protected (or class-protected) allows the class itself and all its subclasses to access the member.

• Public means that any code can access the member by its name.

Inheritance (object-oriented programming)

From Wikipedia, the free encyclopedia

In object-oriented programming (OOP), Inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviors called objects which can be based on previously created objects. In classical inheritance where objects are defined by classes, classes can inherit other classes. The new classes, known as Sub-classes (or derived classes), inherit attributes and behavior of the pre-existing classes, which are referred to as Super-classes (or ancestor classes). The inheritance relationship of sub- and superclasses gives rise to a hierarchy. In Prototype-based programming objects can be defined directly from other objects without the need to define any classes.

The inheritance concept was invented in 1967 for Simula.^[1]

Prata:

The special relationship between a derived class and a base class is based on an underlying model for C++ inheritance. Actually, C++ has three varieties of inheritance: public, protected, and private. Public inheritance is the most common form, and it models an is-a relationship. This is shorthand for saying that an object of a derived class should also be an object of the base class. Anything you do with a base-class object, you should be able to do with a derived class object. Suppose, for example, that you have a Fruit class. It could store, say, the weight and caloric content of a fruit. Because a banana is a particular kind of fruit, you could derive a Banana class from the Fruit class. The new class would inherit all the data members of the original class, so a Banana object would have members representing the weight and caloric content of a banana. The new Banana class also might add members that apply particularly to bananas and not to fruit in general, such as the Banana Institute Peel Index. Because the derived class can add features, it’s probably more accurate to describe the relationship as an is-a-kind-of relationship, but is-a is the usual term.

To clarify is-a relationships, let’s look at some examples that don’t match that model. Public inheritance doesn’t model a has-a relationship. A lunch, for example, might contain a fruit. But a lunch, in general, is not a fruit. Therefore, you should not derive a Lunch class from the Fruit class in an attempt to place fruit in a lunch. The correct way to handle putting fruit into a lunch is to consider the matter as a has-a relationship: A lunch has a fruit. As you’ll see in Chapter 14, that’s most easily modeled by including a Fruit object as a data member of a Lunch class.

Public inheritance doesn’t model an is-implemented-as-a relationship. For example, you could implement a stack by using an array. However, it wouldn’t be proper to derive a Stack class from an Array class. A stack is not an array. For example, array indexing is not a stack property. Also, a stack could be implemented in some other way, such as by using a linked list. A proper approach would be to hide the array implementation by giving the stack a private Array object member. Public inheritance doesn’t model a uses-a relationship. For example, a computer can use a laser printer, but it doesn’t make sense to derive a Printer class from a Computer class, or vice versa. You might, however, devise friend functions or classes to handle communication between Printer objects and Computer objects.

Wikipedia:

Whereas public inheritance represents an "is-a" relationship and delegation represents a "has-a" relationship, private (and protected) inheritance can be thought of as an "is implemented in terms of" relationship.