CSC/ECE 517 Fall 2011/ch1 2b qu

Access Control in o-o Languages

O-o languages have different approaches to controlling access to variables and methods. Ruby, for example, doesn't allow an object to access the private features of another object, even if the other object is an instance of the same class. Java 1.0 had a "private protected" access specifier that allowed subclasses to access a variable, but not non-subclasses in the same package. It was dropped, probably because it was confusing. Have philosophies about allowing access become more restrictive over the years, as accessor methods have become more prominent?

Introduction

Access control is a feature that is available in many programming languages that allows the programmer to define a set of rules that govern how the elements in a program (for example methods or attributes in a class) can be used from different contexts. While some programming languages like C++, JAVA etc have predefined policies for access control (public/protected/private) allowing structured but limited power in the hands of the programmer, others such as Eiffel provide more flexible access control scheme (selective export). Here, we will look at access control policies of some object-oriented programming languages and how these policies have changed over the years.

Why Access Control?

Access control is a key component of Encapsulation/Data Hiding principle in object-oriented languages. The data hiding principle emphasizes on the importance of separating the design decisions from the rest of the program so that when a decision is changed, the rest of the program does not have to be extensively modified. In o-o languages this is done by hiding the internals/implementation details of a class from the user. The access to selected components/functions of class is allowed through an interface (for example a method) thus prohibiting their direct modification by the user. This protects the object's integrity by preventing users from setting the internal data of the object into an invalid or inconsistent state.

For example, a class Employee may have methods such as name, department, position and salary, that return the employee's name, department, position within the organization and salary respectively. The details about how the name method gets the name of the employee or how is the salary calculated should not be available to the users of the Employee class. The name method may connect to the database to retrieve the values or the salary method may query another database that records the employees hourly attendance to calculate the current salary. The codes for performing these tasks is not relevant to the user and should not be exposed. Access control allows the programmer to selectively hide the data/implementation details.