Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch6 6b ss

2011-11-20T00:53:37Z

Speri:

<p style="font-size: 20px">''' Subclassing '''

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webopedia.com/TERM/B/base_class.html base class](superclass/ parent class) by inheriting the methods and instance data from the base class.

==Why do we Subclass?==
* Code reuse
* Specialization: A subclass can define new methods it's superclass does not handle.
* Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==

===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the '''Liskov Substitution Principle(LSP)''' which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}

==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass

===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is the mechanism by which one can achieve categorization and it it also facilitates polymorphism. Inheritance is used to build a hierarchy of concepts separated in categories at different levels of abstraction.

===Is-A Perspective===
Now let us consider both "[http://en.wikipedia.org/wiki/Is-a is-a]" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.

===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

==Conclusion==

===Is Liskov Substitution Principle restrictive?===

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract]. The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype. When using Design by Contract, subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

==References==
* http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

* http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

* http://en.wikipedia.org/wiki/Code_reuse

* http://www.isase.us/wisr3/7.pdf

* http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

* [http://dl.acm.org/citation.cfm?id=62141 Keynote address - data abstraction and hierarchy], Barbara Liskov, MIT Laboratory for Computer Science, Cambridge, Ma.

* http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

* http://www.objectmentor.com/resources/articles/lsp.pdf

CSC/ECE 517 Fall 2011/ch6 6b ss

2011-11-17T16:08:15Z

Speri:

<p style="font-size: 20px">''' Subclassing '''

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webopedia.com/TERM/B/base_class.html base class](superclass/ parent class) by inheriting the methods and instance data from the base class.

==Why do we Subclass?==
* Code reuse
* Specialization: A subclass can define new methods it's superclass does not handle.
* Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==

===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the '''Liskov Substitution Principle(LSP)''' which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}

==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass

===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "[http://en.wikipedia.org/wiki/Is-a is-a]" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.

===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

==Conclusion==

===Is Liskov Substitution Principle restrictive?===

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract]. The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype. When using Design by Contract, subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

LiskovSubstitutionPrinciple is about subtyping, which relates strongly to polymorphism. Polymorphism is the source of most of the power of OO and the power comes from the re-use that comes from subclassing. Polymorphism is what makes it possible for the clients of an interface (those dependent on a type) to not care which implementation is used at any point in the code. Subclassing makes it possible to re-use the methods provided by a superclass to provide different behavior.

==References==
* http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

* http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

* http://en.wikipedia.org/wiki/Code_reuse

* http://www.isase.us/wisr3/7.pdf

* http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

* [http://dl.acm.org/citation.cfm?id=62141 Keynote address - data abstraction and hierarchy], Barbara Liskov, MIT Laboratory for Computer Science, Cambridge, Ma.

* http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

* http://www.objectmentor.com/resources/articles/lsp.pdf

CSC/ECE 517 Fall 2011/ch6 6b ss

2011-11-17T16:06:16Z

Speri:

<p style="font-size: 20px">''' Subclassing '''

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webopedia.com/TERM/B/base_class.html base class](superclass/ parent class) by inheriting the methods and instance data from the base class.

==Why do we Subclass?==
* Code reuse
* Specialization: A subclass can define new methods it's superclass does not handle.
* Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==

===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the '''Liskov Substitution Principle(LSP)''' which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}

==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass

===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "[http://en.wikipedia.org/wiki/Is-a is-a]" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.

===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

==Conclusion==

===Is Liskov Substitution Principle restrictive?===

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

/* This talks about behavioral subtyping which has almost same constraints as LSP Dont think we can mention it here*/
But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract]. The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype. When using Design by Contract, subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

LiskovSubstitutionPrinciple is about subtyping, which relates strongly to polymorphism. Polymorphism is the source of most of the power of OO and the power comes from the re-use that comes from subclassing. Polymorphism is what makes it possible for the clients of an interface (those dependent on a type) to not care which implementation is used at any point in the code. Subclassing makes it possible to re-use the methods provided by a superclass to provide different behavior.

==References==
* http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

* http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

* http://en.wikipedia.org/wiki/Code_reuse

* http://www.isase.us/wisr3/7.pdf

* http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

* [http://dl.acm.org/citation.cfm?id=62141 Keynote address - data abstraction and hierarchy], Barbara Liskov, MIT Laboratory for Computer Science, Cambridge, Ma.

* http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

* http://www.objectmentor.com/resources/articles/lsp.pdf

CSC/ECE 517 Fall 2011/ch6 6b ss

2011-11-17T16:04:35Z

Speri: Created page with "''' Subclassing ''' ==Subclassing== Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a ..."

''' Subclassing '''

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webopedia.com/TERM/B/base_class.html base class](superclass/ parent class) by inheriting the methods and instance data from the base class.

==Why do we Subclass?==
* Code reuse
* Specialization: A subclass can define new methods it's superclass does not handle.
* Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==

===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the '''Liskov Substitution Principle(LSP)''' which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}

==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass

===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "[http://en.wikipedia.org/wiki/Is-a is-a]" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.

===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

==Conclusion==

===Is Liskov Substitution Principle restrictive?===

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

/* This talks about behavioral subtyping which has almost same constraints as LSP Dont think we can mention it here*/
But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract]. The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype. When using Design by Contract, subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

LiskovSubstitutionPrinciple is about subtyping, which relates strongly to polymorphism. Polymorphism is the source of most of the power of OO and the power comes from the re-use that comes from subclassing. Polymorphism is what makes it possible for the clients of an interface (those dependent on a type) to not care which implementation is used at any point in the code. Subclassing makes it possible to re-use the methods provided by a superclass to provide different behavior.

==References==
* http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

* http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

* http://en.wikipedia.org/wiki/Code_reuse

* http://www.isase.us/wisr3/7.pdf

* http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

* [http://dl.acm.org/citation.cfm?id=62141 Keynote address - data abstraction and hierarchy], Barbara Liskov, MIT Laboratory for Computer Science, Cambridge, Ma.

* http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

* http://www.objectmentor.com/resources/articles/lsp.pdf

CSC/ECE 517 Fall 2011

2011-11-17T16:03:43Z

Speri:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f mm]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h as]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[CSC/ECE 517 Fall 2011/ch17 5b uo]]

*[[CSC/ECE 517 Fall 2011/ch17 5b br]]

*[[CSC/ECE 517 Fall 2011/ch5 5d he]]

*[[CSC/ECE 517 Fall 2011/ch5 6d ny]]

*[[CSC/ECE 517 Fall 2011/ch6 6d sk]]

*[[CSC/ECE 517 Fall 2011/ch6 6e ch]]

*[[CSC/ECE 517 Fall 2011/ch6 6b ss]]

*[[CSC/ECE 517 Fall 2011/ch6 6b ra]]

*[[CSC/ECE 517 Fall 2011/ch6 6c sj]]

*[[CSC/ECE 517 Fall 2011/ch6 6a am]]

*[[CSC/ECE 517 Fall 2011/ch6 6e zj]]

*[[CSC/ECE_517_Fall_2011/ch6 6e gm]]

*[[CSC/ECE 517 Fall 2011/ch6 6f jd]]

*[[CSC/ECE 517 Fall 2011/ch6 6f va]]

*[[CSC/ECE 517 Fall 2011/ch6 6c p]]

*[[CSC/ECE 517 Fall 2011/ch6 6e gm]]

*[[CSC/ECE 517 Fall 2011/ch6 6c sm]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch1 6b ss

2011-11-17T16:01:58Z

Speri:

CSC/ECE 517 Fall 2011/ch1 6b ss

2011-11-17T15:56:25Z

Speri: Created page with "=='''Subclassing'''== Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webo..."

=='''Subclassing'''==

Subclassing is a principle of creating a specialization(subclass/ [http://www.webopedia.com/TERM/D/derived_class.html derived class]) of a [http://www.webopedia.com/TERM/B/base_class.html base class](superclass/ parent class) by inheriting the methods and instance data from the base class.

==Why do we Subclass?==
* Code reuse
* Specialization: A subclass can define new methods it's superclass does not handle.
* Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==

===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the '''Liskov Substitution Principle(LSP)''' which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}

==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass

===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "[http://en.wikipedia.org/wiki/Is-a is-a]" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.

===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

==Conclusion==

===Is Liskov Substitution Principle restrictive?===

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

/* This talks about behavioral subtyping which has almost same constraints as LSP Dont think we can mention it here*/
But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract]. The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype. When using Design by Contract, subclasses in an inheritance hierarchy are allowed to weaken preconditions (but not strengthen them) and strengthen postconditions and invariants (but not weaken them). These rules approximate behavioral subtyping.

LiskovSubstitutionPrinciple is about subtyping, which relates strongly to polymorphism. Polymorphism is the source of most of the power of OO and the power comes from the re-use that comes from subclassing. Polymorphism is what makes it possible for the clients of an interface (those dependent on a type) to not care which implementation is used at any point in the code. Subclassing makes it possible to re-use the methods provided by a superclass to provide different behavior.

==References==
* http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

* http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

* http://en.wikipedia.org/wiki/Code_reuse

* http://www.isase.us/wisr3/7.pdf

* http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

* [http://dl.acm.org/citation.cfm?id=62141 Keynote address - data abstraction and hierarchy], Barbara Liskov, MIT Laboratory for Computer Science, Cambridge, Ma.

* http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple

* http://www.objectmentor.com/resources/articles/lsp.pdf

Http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE 517 Fall 2011/ch6 6b ss

2011-11-17T15:52:54Z

Speri: moved Http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE 517 Fall 2011/ch6 6b ss to Mywiki2 over redirect

#REDIRECT [[Mywiki2]]

Mywiki2

2011-11-17T15:52:54Z

Speri: moved Http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE 517 Fall 2011/ch6 6b ss to Mywiki2 over redirect

Mywiki2

2011-11-17T15:51:35Z

Speri: moved Mywiki2 to Http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE 517 Fall 2011/ch6 6b ss

Mywiki2

2011-11-16T16:31:55Z

Speri:

Mywiki2

2011-11-13T04:46:53Z

Speri:

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and instance data from the baseclass.

==Why do we Subclass?==
1. Code reuse
2. Specialization: A subclass can define new methods it's superclass does not handle.
3. Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==
===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the Liskov Substitution Principle which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}
==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass
===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "is-a" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.
===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

Is Liskov Substitution Principle restrictive?

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle while subclassing as it is one of the most powerful OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user about the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up of class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

But again, if the developer is solely interested in achieving code reuse and if he finds Liskov Substitution Principle to be too restrictive then he can achieve the same using alternative methodologies such as [http://en.wikipedia.org/wiki/Design_by_contract Design By Contract].

The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype.

/*lifted (ll modify it latr*/
LiskovSubstitutionPrinciple is about subtyping, which relates strongly to polymorphism. To my way of thinking, polymorphism is the source of most of the power of OO. I think there must be people who believe the power comes from the re-use that comes from subclassing. Polymorphism is what makes it possible for the clients of an interface (those dependent on a type) to not care which implementation is used at any point in the code. Subclassing makes it possible to re-use the methods provided by a superclass to provide different behavior.

==References==
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

http://en.wikipedia.org/wiki/Code_reuse

http://www.isase.us/wisr3/7.pdf

http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

Mywiki2

2011-11-13T04:41:01Z

Speri:

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and instance data from the baseclass.

==Why do we Subclass?==
1. Code reuse
2. Specialization: A subclass can define new methods it's superclass does not handle.
3. Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==
===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the Liskov Substitution Principle which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}
==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass
===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "is-a" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.
===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

Is Liskov Substitution Principle restrictive?

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But one can also achieve code reuse using [http://en.wikipedia.org/wiki/Delegation_(programming) Delegation] and [http://en.wikipedia.org/wiki/Composition_over_inheritance Composition] which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle which is one of the good OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user regarding the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

But again if the developer is solely interested in achieving code re-use and if he finds Liskov Substitution Principle to be too restrictive then he can achieve it using alternate methodologies such as DesignByContract.

The idea of DBC is to specify that part of the behaviour which must remain unchanged (by means of assertions and suchlike). This leads to a more precise notion of subtype.

==References==
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

http://en.wikipedia.org/wiki/Code_reuse

http://www.isase.us/wisr3/7.pdf

http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

Mywiki2

2011-11-13T04:32:16Z

Speri:

==Subclassing==

Subclassing is a principle of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and instance data from the baseclass.

==Why do we Subclass?==
1. Code reuse
2. Specialization: A subclass can define new methods it's superclass does not handle.
3. Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.

==Is Subclassing same as Subtyping?==
===Subtyping===
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the Liskov Substitution Principle which states,

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of
P is unchanged when o1 is substituted for o2, then S is a subtype of T.

In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].

'''Subclass not Subtype'''

class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}

'''Subtype'''
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}

class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}
==Four perspectives of Inheritance==
The four perspectives help in determining when to subclass
===Code Reuse===

Code reuse is the practice of using the same segment of code in multiple applications.

''''Is Code Reuse alone a sufficient reason to use Inheritance?''''
No It is not.

Consider the following example.
<pre>
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;

void setManufacturerName(String mname)
{manufacterer_name=mname;
}

int getPartID()
{return part_id;
}

}

class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
</pre>

Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.

So Code Reuse is in itself not a sufficient reason for using inheritance.

So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.

''''Then what is Inheritance for?''''

Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.

===Is-A Perspective===
Now let us consider both "is-a" relationship and Code reuse perspectives.

''''Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?''''

Consider the following example.
<pre>
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}

class Penguin extends Birds
{
void fly()
{
throw new Exception();
}

void altitude()
{
throw new Exception();
}

}
</pre>
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.

Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.

This violates the Principle of Least Astonishment

If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B,
there should be no surprises when he sends messages to the object.

So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.

This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.

Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.
===Public Interface Perspective/ Behavioral subtyping===

Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).

interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A

Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called '''behavioral subtyping''', and A is a subtype of B. For behavioral subtyping, LSP has to be followed.

[http://cs.colby.edu/djskrien/ Dale Skrien], in his [http://search.barnesandnoble.com/Object-Oriented-Design-Using-Java/Dale-Skrien/e/9780072974164?cm_mmc=borders-_-sku-_-NA-_-NA&redir=borders book], suggests the following guideline for subclassing,
"If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."

An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold

class Person{
String name;
...
...
}

class Student extends Person{
...
}

class Employee extends Person{
...
}

Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.

===Polymorphism===

If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.

Is Liskov Substitution Principle restrictive?

It depends,
If the developer in solely interested in reusing the code rather than keeping the behaviour or semantics of the methods intact, then he can do so by using sub-classing .But he can also achieve code reuse using Delegation and Composition which are relatively difficult to implement when compared to inheritance .But it is a good practice not to violate LSP principle which is one of the good OO design principles which leads to good OO design.Furthermore,it provides more clarity to the user regarding the behaviour of the inherited methods inside the sub classes.Violation of LSP principle leads to messing up class hierarchies. Mess being that whenever a subclass instance was passed as parameter to any method, strange behavior would occur.

==References==
http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html

http://en.wikipedia.org/wiki/Code_reuse

http://www.isase.us/wisr3/7.pdf

http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/

Mywiki2

2011-11-12T01:59:50Z

Speri:

Mywiki2

2011-11-12T00:23:05Z

Speri:

CSC/ECE 517 Fall 2011

2011-09-23T00:33:28Z

Speri:

CSC/ECE 517 Fall 2011/ch2 2b sa

2011-09-23T00:09:39Z

Speri: Created page with "'''Access Control in Object Oriented Languages''' :Each Object Oriented Language has its own way of implementing Access Control .This page discusses the various ways in which Ac..."

'''Access Control in Object Oriented Languages'''
:Each Object Oriented Language has its own way of implementing Access Control .This page discusses the various ways in which Access control is implemented in some of the Object Oriented Languages.
=='''Access Control'''==
Access control in programming languages provides the programmer the ability to define standards that are needed to hide the implementation of the modules from the public interface.Access control provides the programmer ,the ability to prevent under privileged users from access to internal components of a program and restricts them from changing the data within the component to an inconsistent state(i.e elements(members functions and variables) within a program(class)) there by protecting the integrity of the components .This concept of hiding the information in object oriented languages is called [http://en.wikipedia.org/wiki/Encapsulation Encapsulation].

==Access Control in Ruby==
Access control in ruby is achieved using the following [http://en.wikipedia.org/wiki/Java_syntax#Access_modifiers access modifiers]for the methods.
*''public'' :The methods that are declared as public can be accessed by any object belong to the class .
*''private'' :The methods that are declared as private can only be invoked in the context of the current object.
*''protected'' :The methods that are declared as protected can be invoked by the objects of both the class and the sub-classes.

In Ruby these modifiers only apply to the methods but not the instance variables.

====Public Methods in Ruby====
Public methods in ruby can be accessed by any object or instance of a Class and its Sub-classes.
Declaration of public methods:

<pre>
class A
def method
puts "hello"
end
end
</pre>

<pre>
class A
def method
puts "hello"
end
public :method
end
</pre>

====Private Methods in Ruby====
private methods in Ruby can only be invoked by the current object in question and one cannot invoke other object's private methods.
In Ruby private methods are not private to the class but they are private to the objects. No method is perfectly private in Ruby.

======Declaration of Private methods======
<pre>
class A
private
def method
end
end

class A
def method
end
private :method
end
</pre>

An example to show that private methods in Ruby can only be invoked by the current object in context.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It gives an error because pubm method is called in the context of object 'a',so only object 'a' can
puts "I am a public method" invoke the private method but not the new object.
end
private :method
end

class B
def m1
method //private methods of the base class can be accessed by the sub class
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

===Protected Methods in Ruby===
protected methods are visible in both the base class as well as the sub-classes(i.e they can be invoked by the objects of both the class and its sub-classes).

Declaration of protected methods is ruby.
<pre>
class A
protected
def method
end
end

class A
def method
end
protected :method
end
</pre>
Unlike private methods ,In Ruby protected methods can be called with an explicit receiver.

<pre>
class A
def method
puts "I am a protected method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
protected :method
end

class B
def m1
method //protected methods of the base class can be accessed by the sub class.
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

In Ruby both the private as well as the protected methods can be accessed from outside the class using send method.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
private :method
end
a=A.new
a.method // gives an error
a.send(:method) // prints "I am a private method"
a.send :method // prints "I am a protected method"
</pre>
==Access Control in C++==

===Controlling Access to the Member Data and Member Functions===

In C++ one can restrict the level of access control on the member data and function using the access specifiers public,private and protected.
A constructor should never be declared as private.
Access control is applied to all the names uniformly.

===Controlling the Level of accessibility of Base class and its Members===
If a class is [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inherited]using a public access specifier than the public members of the base class are inherited as the public members of the derived class and protected members of the base class are inherited as the protected members of the derived class.If a class is inherited using a private access specifier than both the public and protected members of the base class become the private members of the derived class.If a class is inherited using a protected access specifier than both the public and protected members of the base class become the protected. members of the derived class.
[[File:Access.png|400px|center|upright=0.56|Diagram Depicting the Visibility of members and the Inheritance effect.]]
However, the sub-class members can determine the values of the base class private members by using the Base class public member functions.

<pre>
class A
{
int a;
public:
int value()
{
a=10;
return a;
}
};
class B:public A
{
public:
int b;
void bvalue()
{
b=value(); //now b is assigned a value 10 .This is how the sub class can determine the value of the base class private member
printf("%d",b); variables
}
};
int main()
{
B o;
o.bvalue();
return 1;
}
</pre>

[http://en.wikipedia.org/wiki/Dynamic_dispatch Dynamic Binding] can be used to access the members of the derived class using the Base class pointer.Dynamic binding or late-binding or run time binding is achieved using virtual functions in the Base class.If the Base class pointer pointing to the derived class object and the matching function is declared virtual in base class, then which function is call is decided at run-time using virtual table entry.

===Friendly Functions===
Like ''send'' method in Ruby,C++ allow the Friend Functions which are not within the scope of the class to access the private members of the class. The friend function are defined like any other function without using either the keyword friend or [http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7l.doc%2Flanguage%2Fref%2Fclrc05cplr175.htm :: scope resolution operator].Since they are not within the scope of the class ,they cannot be called using the objects of the class.Declaration of a friend function in either the public or private part of the class does not change it functionality.

===Friend Classes===
A class declared as a [http://en.wikipedia.org/wiki/Friend_class friend class] of an another class can access all the private and protected members of the class extending friendship.

==Access Control in Java==
Access control can be defined as the methods that limit accessibility of the resources to a set of users or programs to enforce integrity, confidentiality or availability constraints.
Java provides two levels of access controls

*"Top Level" – Public, or Package-Private (no explicit modifier, also known as default).

*"Member Level" – Public, Private, Protected or Package-Private (no explicit modifier, also known as default).
===Top Level===
On the Top level come classes and interfaces. An Interface can only be declared as public. While a class can be declared to be either public or default. If a class is declared as public then it is visible to all the classes in the same or a different package. But if a class is declared with no access specifier i.e. default, then it is public in its own package i.e. it cannot be accessed outside the package other than the one in which it is declared.
===Member Level===
At the member level we can declare fields, methods and constructors as public, private, protected and default. Public and default modifiers are used in the same way as the top level and with the same meaning. When a member of a class is declared as private then it can be accessed only within the class. Also, when a member is declared as protected then it can be accessed by all the classes in the same package and the sub classes (of its class) in other packages.

====Example====
To understand it in more detail consider the following the example.
In the example each package contains two classes. Class C is a sub class of class A. Assuming class A as public then its members can be accessed like –
Class A – It can access all its members independent of their access modifier.
Class B – It can access all the members of class A except those are private.
Class C – It can access public and protected members of class A because it is a sub class of class A.
Class D – It can access only the public members of class A.
The access modifiers of the top level component govern whether its members are available in the other packages i.e. even if we are having public methods in a class but the class is declared as default then its methods will not be available in other packages.
If one’s class is going to be used by other coders then he must ensure that errors due to misuse do not happen. For this he must provide the most restrictive access to its members like always declare the fields as private and provide methods to access/modify them.

==Access Control in C#==
The accessibility levels of the types (class, interface, struct, enum etc.) and the members, controls whether they can be used from the other code in our assembly (*) or other assemblies.

===Accessibility levels provided by C#===

*"Public": It can be used for the types and type members. It allows them to be accessed everywhere in the same assembly or the other assembly.
*"Private": It can be used only for the members. Private members are accessible only within the class or the struct in which they are declared.
*"Protected": It is a member access modifier. It allows the class to hide its members from the other classes except the child classes.
*"Internal": It can be used both for the types and type members. Internal types and members are accessible only by the code in the same assembly.
*"Protected Internal": It’s a combination of protected and internal modifier. It allows the types and the members to be used by any code in the same assembly or by any derived class in another assembly. A protected internal element can be accessed in a derived class in another assembly by using an instance of the derived class.
[[File:Access2.png|400px|center|upright=0.56]]

Usage of these access modifiers for all types or members is dependent on the conditions like the accessibility of the container restricts the accessibility of a type member.
*- Assembly is a physical unit that can be executed, deployed, versioned and secured.

==Conclusion==
The philosophies of access controls in object oriented languages have not changed much over time but certainly the access control across different Object Oriented Languages are different if not completely.

==References==
# http://ruby-doc.org/core/
# http://rubylearning.com/satishtalim/ruby_access_control.html
# http://phrogz.net/programmingruby/tut_classes.html
# http://msdn.microsoft.com/en-us/library/kktasw36(v=VS.80).aspx
# http://www.kuzbass.ru:8086/docs/isocpp/access.html
# http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr130.htm
# http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
# http://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx
# http://stackoverflow.com/questions/2084801/c-using-declaration-scope-and-access-control

User:Speri

2011-09-22T23:52:55Z

Speri:

'''Access Control in Object Oriented Languages'''
:Each Object Oriented Language has its own way of implementing Access Control .This page discusses the various ways in which Access control is implemented in some of the Object Oriented Languages.
=='''Access Control'''==
Access control in programming languages provides the programmer the ability to define standards that are needed to hide the implementation of the modules from the public interface.Access control provides the programmer ,the ability to prevent under privileged users from access to internal components of a program and restricts them from changing the data within the component to an inconsistent state(i.e elements(members functions and variables) within a program(class)) there by protecting the integrity of the components .This concept of hiding the information in object oriented languages is called [http://en.wikipedia.org/wiki/Encapsulation Encapsulation].

==Access Control in Ruby==
Access control in ruby is achieved using the following [http://en.wikipedia.org/wiki/Java_syntax#Access_modifiers access modifiers]for the methods.
*''public'' :The methods that are declared as public can be accessed by any object belong to the class .
*''private'' :The methods that are declared as private can only be invoked in the context of the current object.
*''protected'' :The methods that are declared as protected can be invoked by the objects of both the class and the sub-classes.

In Ruby these modifiers only apply to the methods but not the instance variables.

====Public Methods in Ruby====
Public methods in ruby can be accessed by any object or instance of a Class and its Sub-classes.
Declaration of public methods:

<pre>
class A
def method
puts "hello"
end
end
</pre>

<pre>
class A
def method
puts "hello"
end
public :method
end
</pre>

====Private Methods in Ruby====
private methods in Ruby can only be invoked by the current object in question and one cannot invoke other object's private methods.
In Ruby private methods are not private to the class but they are private to the objects. No method is perfectly private in Ruby.

======Declaration of Private methods======
<pre>
class A
private
def method
end
end

class A
def method
end
private :method
end
</pre>

An example to show that private methods in Ruby can only be invoked by the current object in context.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It gives an error because pubm method is called in the context of object 'a',so only object 'a' can
puts "I am a public method" invoke the private method but not the new object.
end
private :method
end

class B
def m1
method //private methods of the base class can be accessed by the sub class
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

===Protected Methods in Ruby===
protected methods are visible in both the base class as well as the sub-classes(i.e they can be invoked by the objects of both the class and its sub-classes).

Declaration of protected methods is ruby.
<pre>
class A
protected
def method
end
end

class A
def method
end
protected :method
end
</pre>
Unlike private methods ,In Ruby protected methods can be called with an explicit receiver.

<pre>
class A
def method
puts "I am a protected method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
protected :method
end

class B
def m1
method //protected methods of the base class can be accessed by the sub class.
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

In Ruby both the private as well as the protected methods can be accessed from outside the class using send method.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
private :method
end
a=A.new
a.method // gives an error
a.send(:method) // prints "I am a private method"
a.send :method // prints "I am a protected method"
</pre>
==Access Control in C++==

===Controlling Access to the Member Data and Member Functions===

In C++ one can restrict the level of access control on the member data and function using the access specifiers public,private and protected.
A constructor should never be declared as private.
Access control is applied to all the names uniformly.

===Controlling the Level of accessibility of Base class and its Members===
If a class is [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inherited]using a public access specifier than the public members of the base class are inherited as the public members of the derived class and protected members of the base class are inherited as the protected members of the derived class.If a class is inherited using a private access specifier than both the public and protected members of the base class become the private members of the derived class.If a class is inherited using a protected access specifier than both the public and protected members of the base class become the protected. members of the derived class.
[[File:Access.png|400px|center|upright=0.56|Diagram Depicting the Visibility of members and the Inheritance effect.]]
However, the sub-class members can determine the values of the base class private members by using the Base class public member functions.

<pre>
class A
{
int a;
public:
int value()
{
a=10;
return a;
}
};
class B:public A
{
public:
int b;
void bvalue()
{
b=value(); //now b is assigned a value 10 .This is how the sub class can determine the value of the base class private member
printf("%d",b); variables
}
};
int main()
{
B o;
o.bvalue();
return 1;
}
</pre>

[http://en.wikipedia.org/wiki/Dynamic_dispatch Dynamic Binding] can be used to access the members of the derived class using the Base class pointer.Dynamic binding or late-binding or run time binding is achieved using virtual functions in the Base class.If the Base class pointer pointing to the derived class object and the matching function is declared virtual in base class, then which function is call is decided at run-time using virtual table entry.

===Friendly Functions===
Like ''send'' method in Ruby,C++ allow the Friend Functions which are not within the scope of the class to access the private members of the class. The friend function are defined like any other function without using either the keyword friend or [http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7l.doc%2Flanguage%2Fref%2Fclrc05cplr175.htm :: scope resolution operator].Since they are not within the scope of the class ,they cannot be called using the objects of the class.Declaration of a friend function in either the public or private part of the class does not change it functionality.

===Friend Classes===
A class declared as a [http://en.wikipedia.org/wiki/Friend_class friend class] of an another class can access all the private and protected members of the class extending friendship.

==Access Control in Java==
Access control can be defined as the methods that limit accessibility of the resources to a set of users or programs to enforce integrity, confidentiality or availability constraints.
Java provides two levels of access controls

*"Top Level" – Public, or Package-Private (no explicit modifier, also known as default).

*"Member Level" – Public, Private, Protected or Package-Private (no explicit modifier, also known as default).
===Top Level===
On the Top level come classes and interfaces. An Interface can only be declared as public. While a class can be declared to be either public or default. If a class is declared as public then it is visible to all the classes in the same or a different package. But if a class is declared with no access specifier i.e. default, then it is public in its own package i.e. it cannot be accessed outside the package other than the one in which it is declared.
===Member Level===
At the member level we can declare fields, methods and constructors as public, private, protected and default. Public and default modifiers are used in the same way as the top level and with the same meaning. When a member of a class is declared as private then it can be accessed only within the class. Also, when a member is declared as protected then it can be accessed by all the classes in the same package and the sub classes (of its class) in other packages.

====Example====
To understand it in more detail consider the following the example.
In the example each package contains two classes. Class C is a sub class of class A. Assuming class A as public then its members can be accessed like –
Class A – It can access all its members independent of their access modifier.
Class B – It can access all the members of class A except those are private.
Class C – It can access public and protected members of class A because it is a sub class of class A.
Class D – It can access only the public members of class A.
The access modifiers of the top level component govern whether its members are available in the other packages i.e. even if we are having public methods in a class but the class is declared as default then its methods will not be available in other packages.
If one’s class is going to be used by other coders then he must ensure that errors due to misuse do not happen. For this he must provide the most restrictive access to its members like always declare the fields as private and provide methods to access/modify them.

==Access Control in C#==
The accessibility levels of the types (class, interface, struct, enum etc.) and the members, controls whether they can be used from the other code in our assembly (*) or other assemblies.

===Accessibility levels provided by C#===

*"Public": It can be used for the types and type members. It allows them to be accessed everywhere in the same assembly or the other assembly.
*"Private": It can be used only for the members. Private members are accessible only within the class or the struct in which they are declared.
*"Protected": It is a member access modifier. It allows the class to hide its members from the other classes except the child classes.
*"Internal": It can be used both for the types and type members. Internal types and members are accessible only by the code in the same assembly.
*"Protected Internal": It’s a combination of protected and internal modifier. It allows the types and the members to be used by any code in the same assembly or by any derived class in another assembly. A protected internal element can be accessed in a derived class in another assembly by using an instance of the derived class.
[[File:Access2.png|400px|center|upright=0.56]]

Usage of these access modifiers for all types or members is dependent on the conditions like the accessibility of the container restricts the accessibility of a type member.
*- Assembly is a physical unit that can be executed, deployed, versioned and secured.

==References==
# http://ruby-doc.org/core/
# http://rubylearning.com/satishtalim/ruby_access_control.html
# http://phrogz.net/programmingruby/tut_classes.html
# http://msdn.microsoft.com/en-us/library/kktasw36(v=VS.80).aspx
# http://www.kuzbass.ru:8086/docs/isocpp/access.html
# http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr130.htm
# http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
# http://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx
# http://stackoverflow.com/questions/2084801/c-using-declaration-scope-and-access-control

User:Speri

2011-09-22T22:10:17Z

Speri:

'''Access Control in Object Oriented Languages'''
:Each Object Oriented Language has its own way of implementing Access Control .This page discusses the various ways in which Access control is implemented in some of the Object Oriented Languages.
=='''Access Control'''==
Access control in programming languages provides the programmer the ability to define standards that are needed to hide the implementation of the modules from the public interface.Access control provides the programmer ,the ability to prevent under privileged users from access to internal components of a program and restricts them from changing the data within the component to an inconsistent state(i.e elements(members functions and variables) within a program(class)) there by protecting the integrity of the components .This concept of hiding the information in object oriented languages is called [http://en.wikipedia.org/wiki/Encapsulation Encapsulation].

==Access Control in Ruby==
Access control in ruby is achieved using the following [http://en.wikipedia.org/wiki/Java_syntax#Access_modifiers access modifiers]for the methods.
*''public'' :The methods that are declared as public can be accessed by any object belong to the class .
*''private'' :The methods that are declared as private can only be invoked in the context of the current object.
*''protected'' :The methods that are declared as protected can be invoked by the objects of both the class and the sub-classes.

In Ruby these modifiers only apply to the methods but not the instance variables.

====Public Methods in Ruby====
Public methods in ruby can be accessed by any object or instance of a Class and its Sub-classes.
Declaration of public methods:

<pre>
class A
def method
puts "hello"
end
end
</pre>

<pre>
class A
def method
puts "hello"
end
public :method
end
</pre>

====Private Methods in Ruby====
private methods in Ruby can only be invoked by the current object in question and one cannot invoke other object's private methods.
In Ruby private methods are not private to the class but they are private to the objects. No method is perfectly private in Ruby.

======Declaration of Private methods======
<pre>
class A
private
def method
end
end

class A
def method
end
private :method
end
</pre>

An example to show that private methods in Ruby can only be invoked by the current object in context.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It gives an error because pubm method is called in the context of object 'a',so only object 'a' can
puts "I am a public method" invoke the private method but not the new object.
end
private :method
end

class B
def m1
method //private methods of the base class can be accessed by the sub class
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

===Protected Methods in Ruby===
protected methods are visible in both the base class as well as the sub-classes(i.e they can be invoked by the objects of both the class and its sub-classes).

Declaration of protected methods is ruby.
<pre>
class A
protected
def method
end
end

class A
def method
end
protected :method
end
</pre>
Unlike private methods ,In Ruby protected methods can be called with an explicit receiver.

<pre>
class A
def method
puts "I am a protected method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
protected :method
end

class B
def m1
method //protected methods of the base class can be accessed by the sub class.
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

In Ruby both the private as well as the protected methods can be accessed from outside the class using send method.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
private :method
end
a=A.new
a.method // gives an error
a.send(:method) // prints "I am a private method"
a.send :method // prints "I am a protected method"
</pre>
==Access Control in C++==

===Controlling Access to the Member Data and Member Functions===

In C++ one can restrict the level of access control on the member data and function using the access specifiers public,private and protected.
A constructor should never be declared as private.
Access control is applied to all the names uniformly.

===Controlling the Level of accessibility of Base class and its Members===
If a class is [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inherited]using a public access specifier than the public members of the base class are inherited as the public members of the derived class and protected members of the base class are inherited as the protected members of the derived class.If a class is inherited using a private access specifier than both the public and protected members of the base class become the private members of the derived class.If a class is inherited using a protected access specifier than both the public and protected members of the base class become the protected. members of the derived class.
[[File:Access.png|400px|center|upright=0.56|Diagram Depicting the Visibility of members and the Inheritance effect.]]
However, the sub-class members can determine the values of the base class private members by using the Base class public member functions.

<pre>
class A
{
int a;
public:
int value()
{
a=10;
return a;
}
};
class B:public A
{
public:
int b;
void bvalue()
{
b=value(); //now b is assigned a value 10 .This is how the sub class can determine the value of the base class private member
printf("%d",b); variables
}
};
int main()
{
B o;
o.bvalue();
return 1;
}
</pre>

[http://en.wikipedia.org/wiki/Dynamic_dispatch Dynamic Binding] can be used to access the members of the derived class using the Base class pointer.Dynamic binding or late-binding or run time binding is achieved using virtual functions in the Base class.If the Base class pointer pointing to the derived class object and the matching function is declared virtual in base class, then which function is call is decided at run-time using virtual table entry.

===Friendly Functions===
Like ''send'' method in Ruby,C++ allow the Friend Functions which are not within the scope of the class to access the private members of the class. The friend function are defined like any other function without using either the keyword friend or [http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7l.doc%2Flanguage%2Fref%2Fclrc05cplr175.htm :: scope resolution operator].Since they are not within the scope of the class ,they cannot be called using the objects of the class.Declaration of a friend function in either the public or private part of the class does not change it functionality.

===Friend Classes===
A class declared as a [http://en.wikipedia.org/wiki/Friend_class friend class] of an another class can access all the private and protected members of the class extending friendship.

==Access Control in Java==
Access control can be defined as the methods that limit accessibility of the resources to a set of users or programs to enforce integrity, confidentiality or availability constraints.
Java provides two levels of access controls

*"Top Level" – Public, or Package-Private (no explicit modifier, also known as default).

*"Member Level" – Public, Private, Protected or Package-Private (no explicit modifier, also known as default).
===Top Level===
On the Top level come classes and interfaces. An Interface can only be declared as public. While a class can be declared to be either public or default. If a class is declared as public then it is visible to all the classes in the same or a different package. But if a class is declared with no access specifier i.e. default, then it is public in its own package i.e. it cannot be accessed outside the package other than the one in which it is declared.
===Member Level===
At the member level we can declare fields, methods and constructors as public, private, protected and default. Public and default modifiers are used in the same way as the top level and with the same meaning. When a member of a class is declared as private then it can be accessed only within the class. Also, when a member is declared as protected then it can be accessed by all the classes in the same package and the sub classes (of its class) in other packages.

====Example====
To understand it in more detail consider the following the example.
In the example each package contains two classes. Class C is a sub class of class A. Assuming class A as public then its members can be accessed like –
Class A – It can access all its members independent of their access modifier.
Class B – It can access all the members of class A except those are private.
Class C – It can access public and protected members of class A because it is a sub class of class A.
Class D – It can access only the public members of class A.
The access modifiers of the top level component govern whether its members are available in the other packages i.e. even if we are having public methods in a class but the class is declared as default then its methods will not be available in other packages.
If one’s class is going to be used by other coders then he must ensure that errors due to misuse do not happen. For this he must provide the most restrictive access to its members like always declare the fields as private and provide methods to access/modify them.

==Access Control in C#==
The accessibility levels of the types (class, interface, struct, enum etc.) and the members, controls whether they can be used from the other code in our assembly (*) or other assemblies.

===Accessibility levels provided by C#===

*"Public": It can be used for the types and type members. It allows them to be accessed everywhere in the same assembly or the other assembly.
*"Private": It can be used only for the members. Private members are accessible only within the class or the struct in which they are declared.
*"Protected": It is a member access modifier. It allows the class to hide its members from the other classes except the child classes.
*"Internal": It can be used both for the types and type members. Internal types and members are accessible only by the code in the same assembly.
*"Protected Internal": It’s a combination of protected and internal modifier. It allows the types and the members to be used by any code in the same assembly or by any derived class in another assembly. A protected internal element can be accessed in a derived class in another assembly by using an instance of the derived class.
[[File:Access2.png|400px|center|upright=0.56]]

Usage of these access modifiers for all types or members is dependent on the conditions like the accessibility of the container restricts the accessibility of a type member.
*- Assembly is a physical unit that can be executed, deployed, versioned and secured.

==References==
# http://ruby-doc.org/core/
# http://rubylearning.com/satishtalim/ruby_access_control.html
# http://phrogz.net/programmingruby/tut_classes.html
# http://msdn.microsoft.com/en-us/library/kktasw36(v=VS.80).aspx
# http://www.kuzbass.ru:8086/docs/isocpp/access.html
# http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr130.htm
# http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
# http://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx

File:Access2.png

2011-09-22T21:59:59Z

Speri:

User:Speri

2011-09-21T01:03:51Z

Speri:

'''Access Control in Object Oriented Languages'''
Each Object Oriented Language has its own way of implementing Access Control .This page discusses the various ways in which Access control is implemented in some of the Object Oriented Languages.
=='''Access Control'''==
Access control in programming languages provides the programmer the ability to define standards that are needed to hide the implementation of the modules from the public interface.Access control provides the programmer ,the ability to prevent under privileged users from access to internal components of a program and restricts them from changing the data within the component to an inconsistent state(i.e elements(members functions and variables) within a program(class)) there by protecting the integrity of the components .This concept of hiding the information in object oriented languages is called [http://en.wikipedia.org/wiki/Encapsulation Encapsulation].

==Access Control in Ruby==
Access control in ruby is achieved using the following [http://en.wikipedia.org/wiki/Java_syntax#Access_modifiers access modifiers]for the methods.
*''public'' :The methods that are declared as public can be accessed by any object belong to the class .
*''private'' :The methods that are declared as private can only be invoked in the context of the current object.
*''protected'' :The methods that are declared as protected can be invoked by the objects of both the class and the sub-classes.

In Ruby these modifiers only apply to the methods but not the instance variables.

====Public Methods in Ruby====
Public methods in ruby can be accessed by any object or instance of a Class and its Sub-classes.
Declaration of public methods:

<pre>
class A
def method
puts "hello"
end
end
</pre>

<pre>
class A
def method
puts "hello"
end
public :method
end
</pre>

====Private Methods in Ruby====
private methods in Ruby can only be invoked by the current object in question and one cannot invoke other object's private methods.
In Ruby private methods are not private to the class but they are private to the objects. No method is perfectly private in Ruby.

======Declaration of Private methods======
<pre>
class A
private
def method
end
end

class A
def method
end
private :method
end
</pre>

An example to show that private methods in Ruby can only be invoked by the current object in context.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It gives an error because pubm method is called in the context of object 'a',so only object 'a' can
puts "I am a public method" invoke the private method but not the new object.
end
private :method
end

class B
def m1
method //private methods of the base class can be accessed by the sub class
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

===Protected Methods in Ruby===
protected methods are visible in both the base class as well as the sub-classes(i.e they can be invoked by the objects of both the class and its sub-classes).

Declaration of protected methods is ruby.
<pre>
class A
protected
def method
end
end

class A
def method
end
protected :method
end
</pre>
Unlike private methods ,In Ruby protected methods can be called with an explicit receiver.

<pre>
class A
def method
puts "I am a protected method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
protected :method
end

class B
def m1
method //protected methods of the base class can be accessed by the sub class.
end
end
a=A.new
b=B.new
a.pubm
a.method //gives an error
b.m1
</pre>

In Ruby both the private as well as the protected methods can be accessed from outside the class using send method.
<pre>
class A
def method
puts "I am a private method"
end
def pubm
method
A.new.method // It does not give an error because in the context of the current object, another object belonging to same
puts "I am a public method" class can invoke the protected method .
end
private :method
end
a=A.new
a.method // gives an error
a.send(:method) // prints "I am a private method"
a.send :method // prints "I am a protected method"
</pre>
==Access Control in C++==

===Controlling Access to the Member Data and Member Functions===

In C++ one can restrict the level of access control on the member data and function using the access specifiers public,private and protected.
A constructor should never be declared as private.
Access control is applied to all the names uniformly.

===Controlling the Level of accessibility of Base class and its Members===
If a class is [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inherited]using a public access specifier than the public members of the base class are inherited as the public members of the derived class and protected members of the base class are inherited as the protected members of the derived class.If a class is inherited using a private access specifier than both the public and protected members of the base class become the private members of the derived class.If a class is inherited using a protected access specifier than both the public and protected members of the base class become the protected. members of the derived class.
[[File:Access.png|400px|center|upright=0.56|Diagram Depicting the Visibility of members and the Inheritance effect.]]
However, the sub-class members can determine the values of the base class private members by using the Base class public member functions.

<pre>
class A
{
int a;
public:
int value()
{
a=10;
return a;
}
};
class B:public A
{
public:
int b;
void bvalue()
{
b=value(); //now b is assigned a value 10 .This is how the sub class can determine the value of the base class private member
printf("%d",b); variables
}
};
int main()
{
B o;
o.bvalue();
return 1;
}
</pre>

[http://en.wikipedia.org/wiki/Dynamic_dispatch Dynamic Binding] can be used to access the members of the derived class using the Base class pointer.Dynamic binding or late-binding or run time binding is achieved using virtual functions in the Base class.If the Base class pointer pointing to the derived class object and the matching function is declared virtual in base class, then which function is call is decided at run-time using virtual table entry.

===Friendly Functions===
Like ''send'' method in Ruby,C++ allow the Friend Functions which are not within the scope of the class to access the private members of the class. The friend function are defined like any other function without using either the keyword friend or [http://publib.boulder.ibm.com/infocenter/lnxpcomp/v7v91/index.jsp?topic=%2Fcom.ibm.vacpp7l.doc%2Flanguage%2Fref%2Fclrc05cplr175.htm :: scope resolution operator].Since they are not within the scope of the class ,they cannot be called using the objects of the class.Declaration of a friend function in either the public or private part of the class does not change it functionality.

===Friend Classes===
A class declared as a [http://en.wikipedia.org/wiki/Friend_class friend class] of an another class can access all the private and protected members of the class extending friendship.

==Access Control in Java==
Access control can be defined as the methods that limit accessibility of the resources to a set of users or programs to enforce integrity, confidentiality or availability constraints.
Java provides two levels of access controls

*"Top Level" – Public, or Package-Private (no explicit modifier, also known as default).

*"Member Level" – Public, Private, Protected or Package-Private (no explicit modifier, also known as default).
===Top Level===
On the Top level come classes and interfaces. An Interface can only be declared as public. While a class can be declared to be either public or default. If a class is declared as public then it is visible to all the classes in the same or a different package. But if a class is declared with no access specifier i.e. default, then it is public in its own package i.e. it cannot be accessed outside the package other than the one in which it is declared.
===Member Level===
At the member level we can declare fields, methods and constructors as public, private, protected and default. Public and default modifiers are used in the same way as the top level and with the same meaning. When a member of a class is declared as private then it can be accessed only within the class. Also, when a member is declared as protected then it can be accessed by all the classes in the same package and the sub classes (of its class) in other packages.

====Example====
To understand it in more detail consider the following the example.
[[File:Access1.png|400px|center]]
In the example each package contains two classes. Class C is a sub class of class A. Assuming class A as public then its members can be accessed like –
Class A – It can access all its members independent of their access modifier.
Class B – It can access all the members of class A except those are private.
Class C – It can access public and protected members of class A because it is a sub class of class A.
Class D – It can access only the public members of class A.
The access modifiers of the top level component govern whether its members are available in the other packages i.e. even if we are having public methods in a class but the class is declared as default then its methods will not be available in other packages.
If one’s class is going to be used by other coders then he must ensure that errors due to misuse do not happen. For this he must provide the most restrictive access to its members like always declare the fields as private and provide methods to access/modify them.

==Access Control in C#==
The accessibility levels of the types (class, interface, struct, enum etc.) and the members, controls whether they can be used from the other code in our assembly (*) or other assemblies.

===Accessibility levels provided by C#===

*"Public": It can be used for the types and type members. It allows them to be accessed everywhere in the same assembly or the other assembly.
*"Private": It can be used only for the members. Private members are accessible only within the class or the struct in which they are declared.
*"Protected": It is a member access modifier. It allows the class to hide its members from the other classes except the child classes.
*"Internal": It can be used both for the types and type members. Internal types and members are accessible only by the code in the same assembly.
*"Protected Internal": It’s a combination of protected and internal modifier. It allows the types and the members to be used by any code in the same assembly or by any derived class in another assembly. A protected internal element can be accessed in a derived class in another assembly by using an instance of the derived class.

Usage of these access modifiers for all types or members is dependent on the conditions like the accessibility of the container restricts the accessibility of a type member.
*- Assembly is a physical unit that can be executed, deployed, versioned and secured.

==References==
# http://ruby-doc.org/core/
# http://rubylearning.com/satishtalim/ruby_access_control.html
# http://phrogz.net/programmingruby/tut_classes.html
# http://msdn.microsoft.com/en-us/library/kktasw36(v=VS.80).aspx
# http://www.kuzbass.ru:8086/docs/isocpp/access.html
# http://download.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html
# http://msdn.microsoft.com/en-us/library/wxh6fsc7.aspx

File:Access1.png

2011-09-19T21:32:08Z

Speri:

File:Access.png

2011-09-19T21:31:24Z

Speri:

[[File:Access.png|400px|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[Myriapoda]]''.]]

File:Access.png

2011-09-19T21:27:30Z

Speri:

[[File:Access.png|200px|left|alt=A cartoon centipede reads books and types on a laptop.|The Wikipede edits ''[[Myriapoda]]''.]]

File:Access.png

2011-09-19T21:23:43Z

Speri:

User:Speri

2011-09-11T16:45:47Z

Speri: Created page with "Riverside]"

[[[Riverside, California|Riverside]]]