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. This protects the object's integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state.
For example, a class Person may have methods such as name and email, that return the person's name and e-mail address respectively. How these methods work is an implementation detail that should not be available to users of the Person class. These methods may, for example, connect to a database to retrieve the values. The database connection code that is used to do this is not relevant to client code and should not be exposed. Language-enforced access control allows us to enforce this.