Abstraction file

Editor's Notes

• #2 By major, we mean that a model without any one of these elements is not object oriented. By minor, we mean that each of these elements is a useful, but not essential, part of the object model.
• #4 Abstraction is one of the fundamental ways that we as humans cope with complexity.
• #9 Abelson and Sussman call this behavior/implementation division an abstraction barrier [45] achieved by applying the principle of least commitment, through which the interface of an object provides its essential behavior, and nothing more [46]. We like to use an additional principle that we call the principle of least astonishment, through which an abstraction captures the entire behavior of some object, no more and no less, and offers no surprises or side effects that go beyond the scope of the abstraction. Square (Coordinates, Color)
• #11  Bundling together of data and functions that operate on data
• #12 Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. For example, consider again the structure of a plant. To understand how photosynthesis works at a high level of abstraction, we can ignore details such as the responsibilities of plant roots or the chemistry of cell walls. Similarly, in designing a database application, it is standard practice to write programs so that they don’t care about the physical representation of data but depend only on a schema that denotes the data’s logical view [52]. In both of these cases, objects at one level of abstraction are shielded from implementation details at lower levels of abstraction.
• #13 Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity.
• #15 there are degrees of information hiding. For example, at the programming language level, C++ provides for public, private, and protected members ([Ellis and Stroustrup, 1990]), and Ada has both private and limited private types ([ARM, 1983]). Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden. Programming languages have long supported encapsulation. For example, subprograms (e.g., procedures, functions, and subroutines), arrays, and record structures are common examples of encapsulation mechanisms supported by most programming languages. Newer programming languages support larger encapsulation mechanisms, e.g., "classes" in Simula ([Birtwistle et al. 1973]), Smalltalk ([Goldberg and Robson, 1983]), and C++, "modules" in Modula ([Wirth, 1983]), and "packages" in Ada.
• #16 Hiding is a relative concept: What is hidden at one level of abstraction may represent the outside view at another level of abstraction. The underlying representation of an object can be revealed, but in most cases only if the creator of the abstraction explicitly exposes the implementation, and then only if the client is willing to accept the resulting additional complexity. If encapsulation was "the same thing as information hiding," then one might make the argument that "everything that was encapsulated was Also hidden." This is obviously not true. For example, even though information may be encapsulated within record structures and arrays, this information is usually not hidden (unless hidden via some other mechanism). It is indeed true that encapsulation mechanisms such as classes allow some information to be hidden. However, these same encapsulation mechanisms also allow some information to be visible. Some even allow varying degrees of visibility, e.g., C++'s public, protected, and private members.
• #18 Simply stated, the abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients. Abstraction and encapsulation are complementary concepts: Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. “No part of a complex system should depend on the internal details of any other part” [50]. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort” [51]. “For abstraction to work, implementations must be encapsulated” [53].
• #19 Principle of encapsulation – data private; read/write functions – Implementation function, reasons for which the class exists In OOP we say that objects are members of classes. What does this mean? A class is thus a description of a number of similar objects. This fits our non-technical understanding of the word class. An object is often called an “instance” of a class.
• #20 In C++ every object must belong to a class. A class is a data type, just like int or double. However, classes are programmer-defined, whereas int and double are defined by the designers of the C++ language.
• #21 “For abstraction to work, implementations must be encapsulated” [53]. In practice, this means that each class must have two parts: an interface and an implementation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.
• #22 If the class’s implementation changes, the class’s clients should not be required to change. • Interfaces define and standardize the ways in which things such as people and systems interact. • A class’s public interface (p. 85) describes the public member functions that are made available to the class’s clients. The interface describes what services (p. 85) clients can use and how to request those services, but does not specify how the class carries out the services. • Separating interface from implementation (p. 84) makes programs easier to modify. Changes in the class’s implementation do not affect the client as long as the class’s interface remains unchanged. • A function prototype (p. 85) contains a function’s name, its return type and the number, types and order of the parameters the function expects to receive. • Once a class is defined and its member functions are declared (via function prototypes), the member functions should be defined in a separate source-code file. • For each member function defined outside of its corresponding class definition, the function name must be preceded by the class name and the binary scope resolution operator (::, p. 86).
• #25 * Each class should provide a constructor (p. 77) to initialize an object of the class when the object is created. A constructor must be defined with the same name as the class. • A difference between constructors and functions is that constructors cannot return values, so they cannot specify a return type (not even void). Normally, constructors are declared public. • C++ requires a constructor call at the time each object is created, which helps ensure that every object is initialized before it’s used in a program. • A constructor with no parameters is a default constructor (p. 77). If you do not provide a constructor, the compiler provides a default constructor. You can also define a default constructor explicitly. If you define a constructor for a class, C++ will not create a default constructor.