432 Object-Based Programming Chapter 8 Software Engineering Observation
432 Object-Based Programming Chapter 8 Software Engineering Observation 8.21 Any static class variables and static class methods exist and can be used even if no objects of that class have been instantiated. 8.16 Data Abstraction and Encapsulation Classes normally hide their implementation details from the clients of the classes. This is called encapsulation or information hiding. As an example of encapsulation, let us consider a data structure called a stack. Think of a stack in terms of a pile of dishes. When a dish is placed on the pile, it is always placed at the top (referred to as pushing the dish onto the stack), and when a dish is removed from the pile, it is always removed from the top (referred to as popping the dish off the stack). Stacks are known as last-in, first-out (LIFO) data structures the last item pushed (inserted) on the stack is the first item popped (removed) from the stack. The programmer can create a stack class and hide from its clients implementation of the stack. Stacks can easily be implemented with arrays and other methods (such as linked lists; see Chapter 19, Data Structures, and Chapter 20, Java Utilities Packages and Bit Manipulation ). A client of a stack class need not know how the stack is implemented. The client simply requires that when data items are placed in the stack, they will be recalled in last-in, first-out order. This concept is referred to as data abstraction, and Java classes define abstract data types (ADTs). Although users might happen to know the details of how a class is implemented, users may not write code that depends on these details. This means that a particular class (such as one that implements a stack and its operations of push and pop) can be replaced with another version without affecting the rest of the system, as long as the public services of that class does not change (i.e., every method still has the same name, return type and parameter list in the new class definition). The job of a high-level language is to create a view convenient for programmers to use. There is no single accepted standard view that is one reason why there are so many programming languages. Object-oriented programming in Java presents yet another view. Most programming languages emphasize actions. In these languages, data exists in support of the actions programs need to take. Data is less interesting than actions, anyway. Data is crude. There are only a few built-in data types, and it is difficult for programmers to create their own new data types. This view changes with Java and the object-oriented style of programming. Java elevates the importance of data. The primary activity in Java is creating new data types (i.e., classes) and expressing the interactions among objects of those data types. To move in this direction, the programming-languages community needed to formalize some notions about data. The formalization we consider is the notion of abstract data types (ADTs). ADTs receive as much attention today as structured programming did over the last two decades. ADTs do not replace structured programming. Rather, they provide an additional formalization to further improve the program development process. What is an abstract data type? Consider the built-in type int. What comes to mind is the notion of an integer in mathematics, but int on a computer is not precisely what an integer is in mathematics. In particular, computer ints are normally quite limited in size. For example, int on a 32-bit machine is limited approximately to the range 2 billion to +2 billion. If the result of a calculation falls outside this range, an error occurs and the Copyright 1992 2002 by Deitel & Associates, Inc. All Rights Reserved. 7/3/01