CSC/ECE 517 Fall 2011/ch1 2b jp
Access control is defined as the ability for a modules implementation to remain hidden behind its public interface. This is achieved in object oriented languages via encapsulation. Access control is closely related to the encapsulation/information hiding principle of object-oriented languages.
Introduction
The term “object oriented programming” was first used by Xerox PARC in Smalltalk programming language so as to refer to the process of using objects as the foundation for computation. Since the introduction of OOP, a large number of modern programming languages are now using the concept. Some of these are FORTRAN,BASIC, and Pascal. There have been some compatibility issues, because many programs were not designed with a OOPs approach in mind. To solve this researcher’s suggested designing languages that used OOP concepts and still retained many of the functions that programmers needed. Examples of this type are Eiffel, Java, and Ruby.
Need for Access Control In OO Languages
One of the key OOP’s concept considered while designing programming languages is encapsulation. Encapsulation will allow a class to hide information from objects that may use the code. For example, the Cat class will have a purr() method. A code will be written which will explain how the cat purrs. Despite this, it is not necessary for Betsy the cat to know how she purrs. Encapsulation makes it easier for the developer to change the code without having to change the code for Betsy. When the structure of class is hidden, it is harder for it to be used in the wrong way.
Encapsulation will basically state which class is allowed to use the members of a certain object. This concept makes it easier for programmers to deal with or avoid errors when developing a program. The members within OOP can be categorized as being protected, public, or private.
Access Control in various OO Languagues
C++ | Java | Ruby | |
---|---|---|---|
Access
control |
Public,protected,private,”friends | public,private,package,protected | private,public,protected |
C++
In C++ we have private, public and protected. Suppose variable “data” is a member of class stack and is private then it can accessed by members and friends of stack class. If the member is public then it has no access restrictions. But if the member is protected then it can be accessed by members and friends of stack class and those classes derived from stack class. The members in class are private by default and those of struct/union are public by default. The example below explains the access specifiers:
struct testA { friend class testC; private: int a; public: int b; protected: int c; }; struct testB : testA { void f() { a = 1; // Cannot be accessed since a is private in testA b = 2; c = 3; } }; struct testC { void f(testA x) { x.a = 4; x.b = 5; x.c = 6; } };
int main() { testA y; y.a = 7; // Cannot be accessed since a is private in testA y.b = 8; y.c = 9; // Cannot be accessed since c is protected in testA testB z; z.a = 10; // Cannot be accessed since a is private in testA z.b = 11; z.c = 12; // Cannot be accessed since c is protected in testA }
C++ also provides access specifiers for derived classes.
class Base_Class { public: int Public_Func(); // Declare a public member. protected: int Protected_Func(); // Declare a protected member. private: int Private_Func(); // Declare a private member. }; // Declare two classes derived from BaseClass. class Derived_Class1 : public BaseClass { }; class Derived_Class2 : private BaseClass { };
In Derived_Class1, the member function Public_Func is a public member and Protected_Func is a protected member because Base_Class is a public base class. Private_Func is private to Base_Class, and it is inaccessible to any derived classes. In Derived_Class2, the functions Public_Func and Protected_Func are considered private members because Base_Class is a private base class. Again, Private_Func is private toBase_Class, and it is inaccessible to any derived classes.
Java
Java provides 4 types of access specifiers Public, Private, Protected and default.
Situation | Public | Protected | default | private |
---|---|---|---|---|
Accessible to class
from same Package? |
yes | yes | yes | no |
Accessible to class
from different Package? |
yes | no,unless it is
a subclass |
no | no |
Public methods, variables and classes can be accessed from anywhere in the file system. The constraint that there should be just one public class per file is enforced.
public class Square { // public class public x, y; // public instance variables }
Private variables and methods has only class level access. Not even subclasses can access those. Such kind off variables can be accessed by getter and setter methods.
public class Square { // public class private double x, y; // private (encapsulated) instance variables public setCorner(int x, int y) { // setting values of private fields this.x = x; this.y = y; } public getCorner() { // setting values of private fields return Point(x, y); } }
Protected methods and variables can be accessed by the same class, its sub classes and those within the same package. While in Default the class, methods and fields have only package level access. Below illustrates an example on Protected and Private access specifiers.
class calculate { protected double x,y; private double z; calculate(double x, double y) { this.x = x; this.y = y; } } class multiplication extends calculate { void prod() { double result = x * y; // z = result; // Since z is private } }
Ruby
The concept of private,protected and public methods in Ruby is somewhere different than it is in languages like Java(the public concept is similar).
Private
In Ruby when a method is declared as private,it means it can never be called with an explicit receiver. This typically means that we can call a private method from within a class it is declared as well as subclasses of this class.Below illustrates an example for private access specifier.
class A def main_method method1 end private def method1 puts "hello from #{self.class}" end end class B < A def main_method method1 end end A.new.main_method B.new.main_method Output hello from A hello from B
However, as soon as we try to use an explicit receiver, even if the receiver is "self", the method call will fail .Below illustrates an example.
class C < A def main_method self.method1 end end C.new.main_method Output alan@alan-ubuntu-vm:~/tmp$ ruby a.rb a.rb:36:in `main_method': private method `method1' called for #<C:0x7f67025a0648> (NoMethodError) from a.rb:40
Thus we see that a private method can never be called from outside the class hierarchy where it is defined.
Protected methods can be called with an implicit receiver,just like a private method,but in addition to this it can be called with an explicit receiver as long as this receiver is self.Below illustrates an example of this:-
class A def main_method method1 end protected def method1 puts "hello from #{self.class}" end end class B < A def main_method method1 end end class C < A def main_method self.method1 end end Output alan@alan-ubuntu-vm:~/tmp$ ruby a.rb hello from A hello from B hello from C
Thus we see here unlike the private method ,call with implicit receiver in class B and explicit receiver in class C both succeed.
Public methods are accessible with any kind of explicit or implicit receiver from anywhere.
Conclusion
In OO languages one of the key principle is encapsulation/data hiding. The examples of different OO programming languages have been illustrated above and how access control helps in achieving encapsulation. With the progress of each OO language the access specifiers definition have been formulated to suit the behaviour of the language.
In java 1.0 release there was the private protected specifier. It had the same behavior of the protected modifier in C++, keeping access to subclasses, but not package members. It didn't fall into the nice progression of adding access, going from private to default to protected to public, as it was more like going from private to private protected to public - bypassing default all together and was hence dropped.
Thus access specifiers are an important concept in OO languages and their importance and need should be understood by programmer's for better progrmming.
References
[1]http://msdn.microsoft.com/en-us/library/7f45fat0(v=vs.80).aspx
[2]http://staff.science.uva.nl/~heck/JAVAcourse/ch4/ss2_2.html
[3]http://en.wikipedia.org/wiki/Class_(computer_programming)
[5]http://www.jvoegele.com/software/langcomp.html