CSC/ECE 517 Fall 2011/ch1 2b jp: Difference between revisions
No edit summary |
(→Ruby) |
||
(20 intermediate revisions by the same user not shown) | |||
Line 4: | Line 4: | ||
== Introduction == | == 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 [http://en.wikipedia.org/wiki/Fortran FORTRAN],[http://en.wikipedia.org/wiki/BASIC BASIC], and [http://en.wikipedia.org/wiki/Pascal_(programming_language) Pascal]. There have been some compatibility issues, because many programs were not designed with a OOPs approach in mind. | The term “object oriented programming” was first used by Xerox PARC in [http://en.wikipedia.org/wiki/Smalltalk_programming_language 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 [http://en.wikipedia.org/wiki/Fortran FORTRAN],[http://en.wikipedia.org/wiki/BASIC BASIC], and [http://en.wikipedia.org/wiki/Pascal_(programming_language) 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. | 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. | ||
Line 11: | Line 11: | ||
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. | 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. | 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 == | == Access Control in various OO Languagues == | ||
Line 35: | Line 35: | ||
=== C++ === | === 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: | In [http://en.wikipedia.org/wiki/C%2B%2B C++] we have private, public and protected. | ||
==== Friend Class in C++ ==== | |||
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: | |||
<pre> | <pre> | ||
Line 49: | Line 52: | ||
}; | }; | ||
struct testB : testA { | struct testB : testA { | ||
void f() { | |||
a = 1; // Cannot be accessed since a is private in testA | |||
b = 2; | |||
c = 3; | |||
} | |||
}; | }; | ||
struct testC { | struct testC { | ||
Line 62: | Line 65: | ||
} | } | ||
}; | }; | ||
</pre> | |||
<pre> | |||
int main() { | int main() { | ||
testA y; | testA y; | ||
Line 76: | Line 81: | ||
</pre> | </pre> | ||
==== Derived Class in C++ ==== | |||
C++ also provides access specifiers for derived classes. | C++ also provides access specifiers for derived classes. | ||
<pre> | <pre> | ||
class Base_Class | class Base_Class | ||
Line 102: | Line 109: | ||
=== Java === | === Java === | ||
Java provides 4 types of access specifiers Public, Private, Protected and default. | [http://en.wikipedia.org/wiki/Java_(programming_language) Java] provides 4 types of access specifiers Public, Private, Protected and default. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 138: | Line 145: | ||
|} | |} | ||
==== Public Methods in Java ==== | |||
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 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. | ||
Line 146: | Line 154: | ||
} | } | ||
</pre> | </pre> | ||
==== Private Methods in Java ==== | |||
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. | 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. | ||
<pre> | <pre> | ||
Line 164: | Line 174: | ||
} | } | ||
</pre> | </pre> | ||
==== Protected Methods in Java ==== | |||
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. | 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. | ||
<pre> | <pre> | ||
Line 191: | Line 202: | ||
} | } | ||
</pre> | </pre> | ||
=== Ruby === | === 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). | The concept of private,protected and public methods in [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is somewhere different than it is in languages like Java(the public concept is similar). | ||
==== Private Methods in Ruby ==== | |||
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. | 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. | ||
Line 218: | Line 229: | ||
A.new.main_method | A.new.main_method | ||
B.new.main_method | B.new.main_method | ||
</pre> | |||
<pre> | |||
Output | Output | ||
Line 233: | Line 245: | ||
end | end | ||
end | end | ||
</pre> | |||
<pre> | |||
C.new.main_method | C.new.main_method | ||
</pre> | |||
<pre> | |||
Output | Output | ||
Line 242: | Line 257: | ||
from a.rb:40 | from a.rb:40 | ||
</pre> | </pre> | ||
Thus we see that a private method can never be called from outside the class hierarchy where it is defined. | Thus we see that a private method can never be called from outside the class hierarchy where it is defined. | ||
==== Protected Methods in Ruby ==== | |||
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:- | 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:- | ||
Line 269: | Line 287: | ||
end | end | ||
end | end | ||
</pre> | |||
<pre> | |||
Output | Output | ||
Line 280: | Line 300: | ||
Thus we see here unlike the private method ,call with implicit receiver in class B and explicit receiver in class C both succeed. | 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 in Ruby ==== | |||
Public methods are accessible with any kind of explicit or implicit receiver from anywhere. | 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/information 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 programming. | |||
== References == | == References == | ||
Line 295: | Line 323: | ||
[6]http://www.jot.fm/issues/issue_2005_05/article3/ | [6]http://www.jot.fm/issues/issue_2005_05/article3/ | ||
[7]http://www.jguru.com/faq/view.jsp?EID=15576 |
Latest revision as of 05:12, 22 September 2011
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.
Friend Class in C++
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 }
Derived Class in C++
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 in Java
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 Methods in Java
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 in Java
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 Methods in Ruby
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 in Ruby
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 in Ruby
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/information 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 programming.
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