Programming CS2130 Language Concepts
Unit 16 Encapsulation and Abstraction Client/Server Model Most modern programming languages provide a means of grouping related services together in some program entity. This entity is variously called a package, a module or a class depending on the particular programming language used. In these notes for definiteness I will use the term module to refer to these entities. A module typically provides a service that is utilised by a client. The interface of a module should provide exactly the information needed by the client to use the service effectively and it is important that the interface should be identified clearly and precisely. Details of how a module fulfils its task is irrelevant to the client and should be hidden. The client is provided with the services it requires at an appropriate level of abstraction; complexity is thus reduced by preventing the unwanted coupling of client activities and the details of the way that the module provides its services. The compiler can check the legality of a client's use of a module by inspecting only the module interface. In C++, Eiffel and Java classes are the primary mechanism of encapsulation and information hiding. Information hiding is provided by designating entities of the class as
public protected private
unrestricted visibility visibility in class and sub-classes for C++ visibility in class, sub-classes and package for Java visibility in class only
In Java grouping classes together in a package provides a secondary mechanism for encapsulation and controlling information visibility: protected fields and methods of a class are visible to other (unrelated) classes of the package as well as to sub-classes whether in the package or not. Java also has a default visibility category (when an explicit public, protected or private is omitted from a method or data member declaration). With the default visibility an entity is visible to all classes in the package, but not to sub-classes which are not part of the package. An `historical' note: in early versions of Java methods or data members could be declared as private protected; this meant that the entity was visible in the class and in sub-classes, but not in unrelated classes even those in the same Java package. This usage, which corresponded to the C++ meaning of protected, appears to have been dropped from later versions of Java. In Ada modules are referred to as packages. The interface of a package and its implementation are separated into a package specification and a package body respectively. This physical separation has several advantages: reduction in the need for recompilation particularly in large systems; a client does not need recompilation when the body of a package that it is using is altered, but only when the specification is changed possibility of providing several different implementations of a service with the same interface possibility of providing only a binary version of the package body; thus protecting proprietary information in the source code.
A Barnes, 2006
1
CS2130/Unit 16
However there are some disadvantages: extra files for separate package specifications and bodies increase in the overall size of the source code as subprogram headings etc. need to be duplicated in the package specification and body. In C++ the interface or specification of a class consists of the declarations of the data members of the class and the declarations (function prototypes) of its methods. The implementation of the methods of a class are usually separated from the specification of the class. For example the following declaration could appear in one file
class SomeClass { public: int someMethod(int somePar); // declaration of other public methods & data members private: void someOtherMethod(); // declarations of other private methods and data members }
In this way the interface to the class is clear and not obscured by details of the implementations of the methods. Then later in the same file or perhaps more usually in a separate file the full definitions would appear:
int SomeClass::someMethod(int somePar) { // implementation of the method ........ } void SomeClass::someOtherMethod() { // implementation of the method ........ }
Note the "double colon" notation class::methodname used when defining a method to specify the class to which the method belongs. Sometimes (usually for short accessor & mutator methods) the implementation of some or all methods can be included in the class specification, in which case the class name and double colon are omitted when a method is defined in the class specification. Note that the double colon notation is only used in C++ when defining methods. To call a method one uses the object.method(parameters) notation as in Java In Eiffel and Java the interface and implementation of a class form a single entity and software tools (such as javadoc) can extract a brief and easily viewable module interface specification from the full module. This approach achieves most of the advantages of separating specification and implementation whilst avoiding most of the disadadvantages. Encapsulation A module is said to encapsulate its contents. Encapsulation provides: modularity by grouping related components together as a named unit information hiding via selective interface specification. which in turn support: program organisation via decomposition into components to perform particular tasks
A Barnes, 2006 2 CS2130/Unit 16
abstraction building by providing abstract data types etc. Various uses of modues are illustrated below starting with simple examples where only source code modularity is gained, then moving onto examples which provide increasing levels of abstraction that provide more valuable forms of modularity. Grouping together related constants, types and subtypes A module can group together a collection of related constants, types and/or subtypes which may be relevant to a number of applications or to a number of packages in a large software system. Such modules normally have only a specification and no body. One example is the standard Ada library package Ada.Characters.Latin_1 which provides names for characters in the standard character set so that (for example) control characters and accented characters can be easily referred to in programs even if these characters are not available on standard computer keyboards.
PACKAGE Ada.Characters.Latin_1 IS NUL : CONSTANT Character := Character'Val(0); -- NUL has internal numerical (ASCII) code 0 ... BEL : CONSTANT Character := Character'Val(7); -- BEL has internal numerical (ASCII) code 7 ... COLON : CONSTANT Character := Character'Val(58); ... UC_E_Acute : CONSTANT Character := Character'Val(201); -- upper case E acute ... END Ada.Characters.Latin_1;
After importing the package with a WITH clause, the entities of the package can be used:
WITH Ada.Characters.Latin_1; ....... Put(Ada.Characters.Latin_1.BEL);
-- ring the terminal bell
or we can make the entities of the package directly visible with a USE clause:
WITH Ada.Characters.Latin_1; USE Ada.Characters.Latin_1; ....... Put(BEL); Put(BEL); -- ring the terminal bell twice
Here is another example of a module without a body (or more accurately a class without any methods) to group together related physical constants.
public class Physics { // physical constants in SI units // speed of light public static final double c = 2.99792458e8; // Planck's constant public static final double h = 6.6260687652e-34; // and so on }
The class could then be used as follows:
double mass; double energy; ........ energy = mass*Physics.c*Physics.c;
A Barnes, 2006 3
// E = mc2
CS2130/Unit 16
In Java 1.5 it is possible to make the static data members (and static methods) of a class directly visible by means of an import static declaration:
import static Physics; ........ energy = mass*c*c; // E = mc2
The modules in this section provide organisational convenience only. Grouping together related subprograms A module can group together a number of related procedures and functions, together with any types and subtypes needed to specify parameter and result types. There are many such packages in the standard Ada libraries, for example Ada.Text_IO, Ada.Calendar and Ada.Character.Handling. For example
PACKAGE Ada.Characters.Handling IS FUNCTION Is_Control(Item : Character) RETURN Boolean; -- returns True if Item is a control character ... FUNCTION Is_Lower(Item : Character) RETURN Boolean; -- returns True if Item is a lowercase letter ... FUNCTION To_Upper(Item : Character) RETURN Character; -- returns corresponding uppercase letter if Item is a lowercase -- letter, otherwise returns the character unchanged FUNCTION To_Upper(Item : String) RETURN String; -- returns the string with all letters converted to uppercase ... END Ada.Characters.Handling;
Normally such modules have both a specification and a body or in Java terms the class has both data members and methods. A Java class which provides only static constants and static methods is analogous to this type of module. .An example of such a class is the standard Java class java.lang.Math which provides the trigonometrical and exponential functions and their inverses (sine, cosine, tangent, logarithm, arc sine etc.). Again we would normally use an import static context clause when using the facilities of the class
import static java.lang.Math; ...... double y = sin(sqrt(2.0));
The modules in this section provide organisational convenience and some abstraction namely procedural abstraction. Abstract Data Objects A module body can encapsulate a hidden data object accessible only via exported subprograms. Direct access to the data object is prevented and the implementation details of the object and of the operations acting upon it can be modified without affecting client programs provided the interface (module specification) is unaltered. The data object is abstract as its properties are defined entirely by the subprograms provided to manipulate it. A client program that uses the object does not require (and cannot affect) any concrete details the object's representation. Such abstract data objects are sometimes referred to as encapsulated data In objects. C one could define a stack as an abstract data object (ADO) as follows: in a header file
A Barnes, 2006 4 CS2130/Unit 16
stack.h one would define the interface to the stack by declaring (but not defining) the
functions to access and update the stack:
/* stack.h */ external void push(int n); external int pop(); int IsEmpty(); /* returns 1 if the stack is empty and 0 if not */
Then in the file stack.c we would define the data structures for the stack (for example a linked list) and provide implementations of these three functions. Direct access to the stack data structure from outside the file stack.c would be prevented by declaring the stack data structure to be static (recall this restricts its scope to the file in which it is declared).
/* stack.c */ typedef struct node { int val; struct node* next; } Node; typedef Node* List; static List stack = null; /* encapsulated data object */
void push(int n) { List tmp = (List)malloc(sizeof(Node)); tmp->val = n; tmp->next = stack; } int pop() { int tmp = stack->val; List head = stack; stack = stack->next; free(head); return tmp; } int IsEmpty() { return (stack == NULL); }
To use this stack `object', client code would simply include the following line at its head:
#include stack.h ....... push(3); push(4); ....... if(!isEmpty()) n = pop(); /etc. */
The details of the implementation of the stack object are completely hidden from the client code. It would be possible to change the implementation of the stack (that is the file stack.c), for example to use an array-based implementation, without changing client code or the header file stack.h in any way. The above code provides a higher degree of abstraction than those in the previous sections; both procedural and data abstraction are provided as the details of both the data structure and of the operations that act upon it are hidden from clients.
A Barnes, 2006 5 CS2130/Unit 16
The nearest analogue of an ADO in Java is a class with a static private data structure and public static access methods.
public class IntStack { private class Node { public int val; public Node next; public Node(int n, Node next) { val =n; this.next = next; } } private class List { public Node head; } private static List stack = new List(); public static void push(int n) { stack.head = new Node(n, stack.head); } public static int pop() { int n = stack.head.value; stack.head = stack.head.next; return n; } public static boolean isEmpty() { return stack.head == null); } }
To use the stack in client code we would do:
IntStack.push(3); IntStack.push(4); ....... if(!IntStack.isEmpty()) { n = IntStack.pop(); }
Abstract Data Types The abstract object approach in the last section is valuable, but has some limitations: A client program can import only one copy of the package providing the data object and is therefore limited to just one instance of the abstract object. This may be sufficient in many applications, but clearly in some circumstances a program may well require several instances of the object. The object's value is 'second class'; it cannot be passed as a parameter to a subprogram nor assigned to a variable etc.. To overcome these restrictions we require a further layer of abstraction to introduce an abstract data type (ADT). Defining an abstract data object creates just one entity, but defining an abstract data type allows many objects with a given set of properties to be created. A module providing an abstract data type will need to export a type name which clients may use to create objects of the abstract type and will also need to export operations
A Barnes, 2006 6 CS2130/Unit 16
(subprograms) that can be applied to instances of the abstract type. In Java the definition of an ADO as in the last section is somewhat awkward; it would be more natural and flexible to define the stack to be an abstract data type (by removing the static qualifiers)
public class Stack { private class Node { public int val; public Node next; public Node(int n, Node next) { val =n; this.next = next; } } private class List { public Node head = null; } private List stack = new List(); public void push(int n) { stack.head = new Node(n, stack.head); } public int pop() { int n = stack.head.val; stack.head = stack.head.next; return n; } public boolean isEmpty() { return stack.head == null); } }
One then defines a single object of this class:
Stack s = new Stack();
Of course this approach is much more flexible than the ADO approach as one could define and use many different stack objects:
Stack s1 = new Stack(); Stack s2 = new Stack(); ....... s1.push(3); s2.push(4); ....... if(!s1.isEmpty()) n = s1.pop();
The language C has no facilities for supporting abstract data types. One can implement a stack type as (say) a linked list and declare many objects of that type. However in C there was no way of hiding the details of the implementation from client code (which therefore has direct access to the data structure). We have, in effect, a concrete (as opposed to an abstract) data type. However in C++ we have classes very similar to those in Java and so can define both ADTs and ADOs. The Ada package mechanism is also sufficiently powerful to support the
A Barnes, 2006 7 CS2130/Unit 16
definition of ADTs as well as ADOs. In Ada we might code a stack ADT similar to the Java one above as follows:
PACKAGE StackADT IS TYPE Stack IS LIMITED PRIVATE; -- details of the type are private (hidden from clients) PROCEDURE Push(N : IN Integer; S :IN OUT Stack); -- push the integer N onto the top of stack S PROCEDURE Pop(N : OUT Integer; S : IN OUT Stack); -- Remove integer from the top of stack S and return it -- via OUT parameter N. -- Raises Constraint_Error if the stack is empty FUNCTION IsEmpty(S : IN Stack) RETURN Boolean; -- Return True if stack S is empty and False otherwise. PROCEDURE Init(S : IN OUT Stack); -- (Re-)Initialise the stack S to empty PRIVATE -- details of the impementation hidden from the client TYPE Node; TYPE Stack IS ACCESS Node; END StackADT;
The public part of the package specification defines a partial view on the type Stack which is adequate for decla...