Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:54:08Z

Narumug4: /* DisadvantagesAdvantages */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with?'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages'''==
The advantages of following Law of Demeter are<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>:
 Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>.

=='''Example==
==='''Java'''===
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

====Customer====
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

====Wallet====
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

====Paperboy====
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

====Code improvement , better design using Law of Demeter====
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

====The New Customer====
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

====The New Wallet====
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

====The New Paperboy====
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

====Reasons that led to better design and code====

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==='''Ruby'''===
While developing software, Law of Demeter are violated often especially in Ruby on Rails which allows to easily navigate between objects based on table relationships.

For example, if you are working on a partial that displays a charge from a credit card statement it wouldn't be surprising to see:

<pre>
charge.statement.customer.name
</pre>

The above code could be used to display the customer's name in the partial. Unfortunately, it assumes statement will have a customer and customer will have a name. This is easily fixed by changing charge to only talk to it's friends.

<pre>
charge.customer_name
</pre>

The simple fix to support this is to define customer_name in charge, and customer_name in statement

<pre>
class Charge
def customer_name
statement.customer_name
end
end

class Statement
def customer_name
customer.name
end
end
</pre>

This change is simple enough. However, as the list of methods that require delegation grows your class can become littered with delegation code.

Fortunately Forwardable is included in the standard library of Ruby. Forwardable allows you delegate method calls to an object, on a method by method basis.

Using Forwardable the above code becomes:

<pre>
class Charge
extend Forwardable
def_delegators :statement, :customer_name
end

class Statement
extend Forwardable
def_delegator :customer, :name, :customer_name
end
</pre>

Forwardable becomes even more valuable when you need to delegate several methods def_delegators :amount_info, :units, :fractions, :currency.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:53:23Z

Narumug4: /* AdvantagesAdvantages */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with?'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages'''==
The advantages of following Law of Demeter are<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>:
 Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example==
==='''Java'''===
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

====Customer====
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

====Wallet====
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

====Paperboy====
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

====Code improvement , better design using Law of Demeter====
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

====The New Customer====
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

====The New Wallet====
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

====The New Paperboy====
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

====Reasons that led to better design and code====

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==='''Ruby'''===
While developing software, Law of Demeter are violated often especially in Ruby on Rails which allows to easily navigate between objects based on table relationships.

For example, if you are working on a partial that displays a charge from a credit card statement it wouldn't be surprising to see:

<pre>
charge.statement.customer.name
</pre>

The above code could be used to display the customer's name in the partial. Unfortunately, it assumes statement will have a customer and customer will have a name. This is easily fixed by changing charge to only talk to it's friends.

<pre>
charge.customer_name
</pre>

The simple fix to support this is to define customer_name in charge, and customer_name in statement

<pre>
class Charge
def customer_name
statement.customer_name
end
end

class Statement
def customer_name
customer.name
end
end
</pre>

This change is simple enough. However, as the list of methods that require delegation grows your class can become littered with delegation code.

Fortunately Forwardable is included in the standard library of Ruby. Forwardable allows you delegate method calls to an object, on a method by method basis.

Using Forwardable the above code becomes:

<pre>
class Charge
extend Forwardable
def_delegators :statement, :customer_name
end

class Statement
extend Forwardable
def_delegator :customer, :name, :customer_name
end
</pre>

Forwardable becomes even more valuable when you need to delegate several methods def_delegators :amount_info, :units, :fractions, :currency.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:52:06Z

Narumug4: /* Who can class A interact with ?Who can class interact with */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with?'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example==
==='''Java'''===
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

====Customer====
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

====Wallet====
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

====Paperboy====
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

====Code improvement , better design using Law of Demeter====
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

====The New Customer====
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

====The New Wallet====
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

====The New Paperboy====
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

====Reasons that led to better design and code====

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==='''Ruby'''===
While developing software, Law of Demeter are violated often especially in Ruby on Rails which allows to easily navigate between objects based on table relationships.

For example, if you are working on a partial that displays a charge from a credit card statement it wouldn't be surprising to see:

<pre>
charge.statement.customer.name
</pre>

The above code could be used to display the customer's name in the partial. Unfortunately, it assumes statement will have a customer and customer will have a name. This is easily fixed by changing charge to only talk to it's friends.

<pre>
charge.customer_name
</pre>

The simple fix to support this is to define customer_name in charge, and customer_name in statement

<pre>
class Charge
def customer_name
statement.customer_name
end
end

class Statement
def customer_name
customer.name
end
end
</pre>

This change is simple enough. However, as the list of methods that require delegation grows your class can become littered with delegation code.

Fortunately Forwardable is included in the standard library of Ruby. Forwardable allows you delegate method calls to an object, on a method by method basis.

Using Forwardable the above code becomes:

<pre>
class Charge
extend Forwardable
def_delegators :statement, :customer_name
end

class Statement
extend Forwardable
def_delegator :customer, :name, :customer_name
end
</pre>

Forwardable becomes even more valuable when you need to delegate several methods def_delegators :amount_info, :units, :fractions, :currency.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:48:11Z

Narumug4: /* Ruby */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example==
==='''Java'''===
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

====Customer====
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

====Wallet====
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

====Paperboy====
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

====Code improvement , better design using Law of Demeter====
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

====The New Customer====
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

====The New Wallet====
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

====The New Paperboy====
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

====Reasons that led to better design and code====

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==='''Ruby'''===
While developing software, Law of Demeter are violated often especially in Ruby on Rails which allows to easily navigate between objects based on table relationships.

For example, if you are working on a partial that displays a charge from a credit card statement it wouldn't be surprising to see:

<pre>
charge.statement.customer.name
</pre>

The above code could be used to display the customer's name in the partial. Unfortunately, it assumes statement will have a customer and customer will have a name. This is easily fixed by changing charge to only talk to it's friends.

<pre>
charge.customer_name
</pre>

The simple fix to support this is to define customer_name in charge, and customer_name in statement

<pre>
class Charge
def customer_name
statement.customer_name
end
end

class Statement
def customer_name
customer.name
end
end
</pre>

This change is simple enough. However, as the list of methods that require delegation grows your class can become littered with delegation code.

Fortunately Forwardable is included in the standard library of Ruby. Forwardable allows you delegate method calls to an object, on a method by method basis.

Using Forwardable the above code becomes:

<pre>
class Charge
extend Forwardable
def_delegators :statement, :customer_name
end

class Statement
extend Forwardable
def_delegator :customer, :name, :customer_name
end
</pre>

Forwardable becomes even more valuable when you need to delegate several methods def_delegators :amount_info, :units, :fractions, :currency.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:44:56Z

Narumug4: /* Example */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example==
==='''Java'''===
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

====Customer====
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

====Wallet====
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

====Paperboy====
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

====Code improvement , better design using Law of Demeter====
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

====The New Customer====
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

====The New Wallet====
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

====The New Paperboy====
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

====Reasons that led to better design and code====

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==='''Ruby'''===

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:37:57Z

Narumug4: /* When and How to identify Law of Demeter */

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
From the above sections we have a good understanding of the law and its benefits, but we haven't yet discussed on how to identify places in existing code where we can apply it and just as important, where not to apply it. The following are the places where we can apply the Law of Demeter
===Chained 'get' statements===
The below statement clearly denotes we are violating the law of demeter since we our access crosses the boundary.
<pre>
value = object.getName().getCountry().getZip()
</pre>
More number of dots is also an indicator of the violation of law.

===Lots of 'temporary' objects===
<pre>
name = object.getName();
country = name.getCountry();
zip = country.getZip();
</pre>
This is equivalent to chained get statement, but broken down into multiple statement, this is little more harder to detect that previous case, but this also clearly violates the law

===Importing or including many classes===
In Java, there is a rule which states that we only import classes that are actually used. These practises are never followed and we always see something like below in our source code.
<pre>
import java.lang.*
import java.io.*;
import java.util.*;
</pre>
With this rule in place, it is not uncommon to see a dozen or so import statements all coming from the same package. If this is happening in our code, it could be a good place to look for obscured examples of violations. If we need to import it, we are coupled to it. If it changes, we may have to change as well. By explicitly importing the classes, we will begin to experience how coupled the classes really are.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example'''==
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

===Customer===
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

===Wallet===
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

===Paperboy===
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

===Code improvement , better design using Law of Demeter===
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

===The New Customer===
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

===The New Wallet===
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

===The New Paperboy===
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

===Reasons that led to better design and code===

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T02:29:38Z

Narumug4:

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
===Chained 'get' statements===
value = object.getName().getCountry().getZip() 
This clearly denotes we are violating the law of demeter since we our access crosses the boundary.
===Importing or including many classes===
In java we tend to include a lot of libraries, this is also an indication of law violation.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Disadvantages<ref name="Disadvantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
In order not to expose the internals of the calling class, many layers of wrapper needs to be added. This introduces overhead in maintaining the wrapper and might introduce significant delay since control has to follow all the wrappers.

=='''Example'''==
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

===Customer===
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

===Wallet===
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

===Paperboy===
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

===Code improvement , better design using Law of Demeter===
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

===The New Customer===
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

===The New Wallet===
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

===The New Paperboy===
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

===Reasons that led to better design and code===

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-27T00:57:14Z

Narumug4:

'''Law of Demeter'''

=='''Introduction'''==
[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD)] states "Only talk to your friends", which means do not talk to friend's friend. By doing this, we don't get to know the internals of our friend. In software terms, a class A should only talk to or invoke methods on closely related classes, class B and should not try to poke around the internals of B to reach a new class C. We have two options in order to achieve this, either class A can directly invoke methods on class C or the interface of class B should be changed to accomodate this call from A, then A will invoke methods on B and B will take care of invoking methods on C internally that would satisfy A's request.

In a way, law of demeter can be thought of a more specialized version of low [http://en.wikipedia.org/wiki/Coupling_(computer_programming) coupling] principle. Object oriented design recommends low coupling for better design and maintainability of software systems. The more loosely the classes are coupled, they become more easily testable. Classes need to directly interact with its collaborators and be shielded from understanding their internal structure. Using the internal knowledge of classes introduces risk of breaking functionality, instead they should talk to well known public interfaces. By doing all this we try to create a more shallow relationship than deeper relationship, which reduces the number of classes which may be affected by changes within the system.

=='''Who can class A interact with ?<ref name="">[http://aspiringcraftsman.com/tag/law-of-demeter Who can class interact with]</ref>'''==
If M is a method belonging to class A, then M may invoke other methods belonging to the following:
 1. Class A
 2. Members of A
 3. Parameters of A
 4. Objects created by M
 5. Objects created by other methods of class A called by M
 6. Globally accessible objects

=='''When and How to identify Law of Demeter'''==
===Chained 'get' statements===
value = object.getName().getCountry().getZip() 
This clearly denotes we are violating the law of demeter since we our access crosses the boundary.
===Importing or including many classes===
In java we tend to include a lot of libraries, this is also an indication of law violation.

=='''Advantages<ref name="Advantages">[http://en.wikipedia.org/wiki/Law_of_Demeter Advantages]</ref>'''==
Reusable code
 Better design
 Less risk of breaking functionality
 Modular code

=='''Example'''==
Law of Demeter is a technique for reducing the 'coupling' between objects in the code. Here is an example based on Java that illustrates the Law of Demeter.
 
A ‘Paperboy’ has to get a payment from a ‘Customer’. There has to be a mechanism used by the paperboy for receiving payments from that customer. Lets assume that the paperboy will run a snippet in order to achieve the above. The definition of each Java class for this example is as follows.

===Customer===
The Customer class can have a first name, a last name, an account number, a shipping address, some method of payment, etc. In this example lets define the customer with just enough functionality to make our illustration of Law of Demeter to work.

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public Wallet getWallet(){
return myWallet;
}
}
</pre>

===Wallet===
Each customer is associated with a wallet by which the payment is made. A wallet can have total money, credits cards, drivers license, different types of currency, etc. For this example we design a pretty simplistic wallet.

<pre>
public class Wallet {
private float value;
public float getTotalMoney() {
return value;
}
public void setTotalMoney(float newValue) {
value = newValue;
}
public void addMoney(float deposit) {
value += deposit;
}
public void subtractMoney(float debit) {
value -= debit;
}
}
</pre>

Now that we have all required information about the customer and his wallet. Lets turn our focus on to the paperboy.

===Paperboy===
In this paperboy class we focus more on the method by which payment is made. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : getPayment() ) which achieves this objective. The typical getPayment method for this illustration is as follows

Paying the Paperboy - getPayment()

<pre>
void getPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
Wallet theWallet = myCustomer.getWallet(); // Wallet of the corresponding customer who has to pay
if (theWallet.getTotalMoney() > payment) {
theWallet.subtractMoney(payment);
} else {
// Other code
}
}
</pre>

This code snippet gets the wallet from the customer, checks to make sure if the customer has the money and transfers it from the customers wallet into the paperboy's wallet.

Lets analyse what is bad about this code. We can actually translate what the code is actually doing into real-language. Apparently, when the paperboy stops by and demands payment, the customer is just going to turn around, let the paperboy take the wallet out of his back pocket, and take out two bucks. This is not the typical how some will handle their wallet.

There are a number of 'real-world' problems with this, not to mention we are trusting the paperboy to be honest and just take out what he's owed. If our future Wallet object holds credit cards, the paperboy has access to those too. The basic problem is that “the paperboy is being exposed to more information than he needs to be”.

The most important concept is the 'Paperboy' class now 'knows' that the customer has a wallet and can manipulate it. When we compile the Paperboy class, it will need the Customer class and the Wallet class. These three classes (Customer, Wallet and Paperboy) are now 'tightly coupled'. If we change the Wallet class, we may have to make changes to both of the other classes.

There is another classic problem that this can create. The customer wallet can be stolen or lost. In this case we can set the Wallet to null like

<pre>
victim.setWallet(null);
</pre>

This seems a reasonable assumption. This code enforces any mandatory value for wallet and there is a certain 'elegance' about using null for this condition but this never handles the paperboy. The code assumes there will be a wallet so the paperboy will get a runtime exception for calling a method on a null pointer. We could fix this by checking for 'null' on the wallet before we call any methods on it, but this starts to clutter the paperboy's class. The real-language description is becoming even worse as more and more complex arises. This makes the design and code more convoluted.

===Code improvement , better design using Law of Demeter===
The example illustrated can be made much better by incorporating proper design and improving the code structures. The proper way to fix the issue to move along the 'real world' scenario.
When the paperboy needs payment, he would approach the customer but he is not going to handle the customer wallet. In fact he won't even know whether the customer has a wallet or not even if he does, he can’t be sure that the customer is willing to pay him.

===The New Customer===
The New customer has design changes such that he no longer has a 'getWallet()' method but it does have a getPayment method. The new customer class is as shown below

<pre>
public class Customer {
private String firstName;
private String lastName;
private Wallet myWallet;
public String getFirstName(){
return firstName;
}
public String getLastName(){
return lastName;
}
public float getPayment(float bill) {
if (myWallet != null) {
if (myWallet.getTotalMoney() > bill) {
theWallet.subtractMoney(payment);
return payment;
}
}
}
}
</pre>

===The New Wallet===
There won’t be any changes in design or the code of the Wallet as it performs the required function without any hassle in this example.

===The New Paperboy===
In this new paperboy class we have a method for getting the payment but this done by customer and not the right of the paperboy as per the previous design. In order to get the payment from the customer the paperboy executes a code snippet. The code snippet is some method in the Paperboy class (eg : requestPayment() ) which achieves this objective. The typical requestPayment method for this illustration is as follows

<pre>
void RequestPayment(Customer myCustomer) {
payment = 2.00; // Payment amount
paidAmount = myCustomer.getPayment(payment);
if (paidAmount == payment) {
// Give customer a receipt
} else {
// Other code
}
</pre>

This had made the code and design much better.

===Reasons that led to better design and code===

The first reason that this is better is because it better models the real world scenario. The Paperboy code is now 'asking' the customer for a payment. The paperboy does not have direct access to the wallet.

The second reason that this is better is because the Wallet class can now change and the paperboy is completely isolated from that change. If the interface to Wallet were to change, the Customer would have to be updated, but that's it. As long as the interface to Customer stays the same, none of the client's of Customer will care that he got a new Wallet. Code will be more maintainable, because changes will not 'ripple' through a large project.

The third and probably most 'object-oriented' answer is that it is now free to change the
implementation of 'getPayment()'. In the old example, the assumption was that the Customer would have a wallet. This led to the null pointer exception. In the real world though, when the paper boy comes, the customer may actually get the two bucks from a jar of change, search between the cushions of his couch or borrow it from his roommate, whatever. All of this is 'Business Logic',and is of no concern to the paper boy. All this could be implemented inside of the getPayment() method, and could change in the future, without any modification to the paper boy code.

Those these above discussion have led to lots of advantages we need to accept the fact that it has made the customer a more complex object.

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Law_of_Demeter Law of demeter(LoD) Law of Demeter]
#[http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf Controlling the Complexity of Software Designs]
#[http://www.ccs.neu.edu/home/lieber/LoD/law_of_demeter_healthy_code-external.pdf Loose Coupling with Demeter]
#[http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf The Paperboy, The Wallet,and The Law Of Demeter]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-26T23:55:03Z

Narumug4: /* Introduction */

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-26T23:53:56Z

Narumug4:

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-26T23:38:16Z

Narumug4:

CSC/ECE 517 Fall 2012

2012-10-26T21:42:42Z

Narumug4:

*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]

CSC/ECE 517 Fall 2012/ch2a 2w25 nr

2012-10-26T21:41:55Z

Narumug4: Created page with "'''Law of Demeter''' =='''Introduction'''=="

'''Law of Demeter'''

=='''Introduction'''==

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-21T01:58:55Z

Narumug4: /* Inheritance is white box */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem]. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is <ref name="whiteboxwiki">[http://en.wikipedia.org/wiki/White-box_testing white box]</ref> and not <ref name="blackboxwiki">[http://en.wikipedia.org/wiki/Black-box_testing black box]</ref>, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Composition_over_inheritance Composition over Inheritance]
#[http://www.codeproject.com/Articles/80045/Composition-VS-Inheritance Deciding between Composition vs Inheritance]
#[http://lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance Composition vs Inheritance]
#[http://eflorenzano.com/blog/2008/05/04/inheritance-vs-composition/ Composition over Inheritance]
#[http://www.jguru.com/faq/view.jsp?EID=27916 Delegation instead of Inheritance]
#[http://timsbrownbaglunch.blogspot.com/2009/12/design-review-and-delegation-vs.html Delegation vs Inheritance]
#[http://www.wordiq.com/definition/Delegation_(programming) Delegation]
#[http://www.ics.uci.edu/~taylor/classes/121/BoochOOD003.pdf Object Oriented Development]
#[http://dl.acm.org/citation.cfm?id=179804 Decomposition/generalization methodology for object-oriented programming]
#[http://dl.acm.org/citation.cfm?id=339990 Two object oriented decomposition methods]
#[http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 Design Patterns]

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-21T01:58:16Z

Narumug4: /* Inheritance is white box */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem]. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box<ref name="whiteboxwiki">[http://en.wikipedia.org/wiki/White-box_testing]</ref> and not black box<ref name="blackboxwiki">[http://en.wikipedia.org/wiki/Black-box_testing]</ref>, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Composition_over_inheritance Composition over Inheritance]
#[http://www.codeproject.com/Articles/80045/Composition-VS-Inheritance Deciding between Composition vs Inheritance]
#[http://lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance Composition vs Inheritance]
#[http://eflorenzano.com/blog/2008/05/04/inheritance-vs-composition/ Composition over Inheritance]
#[http://www.jguru.com/faq/view.jsp?EID=27916 Delegation instead of Inheritance]
#[http://timsbrownbaglunch.blogspot.com/2009/12/design-review-and-delegation-vs.html Delegation vs Inheritance]
#[http://www.wordiq.com/definition/Delegation_(programming) Delegation]
#[http://www.ics.uci.edu/~taylor/classes/121/BoochOOD003.pdf Object Oriented Development]
#[http://dl.acm.org/citation.cfm?id=179804 Decomposition/generalization methodology for object-oriented programming]
#[http://dl.acm.org/citation.cfm?id=339990 Two object oriented decomposition methods]
#[http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 Design Patterns]

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-21T01:55:24Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem]. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Composition_over_inheritance Composition over Inheritance]
#[http://www.codeproject.com/Articles/80045/Composition-VS-Inheritance Deciding between Composition vs Inheritance]
#[http://lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance Composition vs Inheritance]
#[http://eflorenzano.com/blog/2008/05/04/inheritance-vs-composition/ Composition over Inheritance]
#[http://www.jguru.com/faq/view.jsp?EID=27916 Delegation instead of Inheritance]
#[http://timsbrownbaglunch.blogspot.com/2009/12/design-review-and-delegation-vs.html Delegation vs Inheritance]
#[http://www.wordiq.com/definition/Delegation_(programming) Delegation]
#[http://www.ics.uci.edu/~taylor/classes/121/BoochOOD003.pdf Object Oriented Development]
#[http://dl.acm.org/citation.cfm?id=179804 Decomposition/generalization methodology for object-oriented programming]
#[http://dl.acm.org/citation.cfm?id=339990 Two object oriented decomposition methods]
#[http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612 Design Patterns]

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-21T01:51:26Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem]. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

==External Links==
#[http://en.wikipedia.org/wiki/Liskov_substitution_principle Liskov substitution principle]
#[http://en.wikipedia.org/wiki/Composition_over_inheritance Composition over Inheritance]
#[http://www.codeproject.com/Articles/80045/Composition-VS-Inheritance Deciding between Composition vs Inheritance]
#[http://lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance Composition vs Inheritance]
#[http://eflorenzano.com/blog/2008/05/04/inheritance-vs-composition/ Composition over Inheritance]
#[http://www.jguru.com/faq/view.jsp?EID=27916 Delegation instead of Inheritance]
#[http://timsbrownbaglunch.blogspot.com/2009/12/design-review-and-delegation-vs.html Delegation vs Inheritance]

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-14T23:03:39Z

Narumug4: /* Problem 1: Multiple Inheritance introduces lot more confusionDiamond Problem */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag#Diamond_Problem_in_Detail Diamond Problem]. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-14T23:02:47Z

Narumug4: /* Delegation */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch6_6a_PC Delegation] is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-14T23:02:15Z

Narumug4: /* Composition */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch3_S30_SK#Decomposition composition] is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-14T23:01:27Z

Narumug4: /* Introduction */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

[http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2010/ch1_25_ag Inheritance] plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object composition is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-13T01:09:42Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object composition is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

[[File:inheritance_uml.png]]

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

[[File:compAgg_uml.png]]

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-13T01:06:19Z

Narumug4: /* Aggregation */

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object composition is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|right|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-13T01:05:57Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object composition is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</ref>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</pre>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|right|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</ref>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

==References==
<references/>

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-13T01:05:06Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance in some cases to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall explain and compare these techniques with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and that will inherit its parent’s attributes and behavior <ref name="inheritance">[http://en.wikipedia.org/wiki/Inheritance_(computer_science) Inheritance]</ref>. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
...
//method definition
}
public void method2() {
...
//method definition
}
}

class B extends A {
public void method1() {
...
//method overriding
}
public void method3() {
...
//new method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and methods defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
In some cases object composition is an alternative to class inheritance to achieve code re-usability. Here, new complex functionality is achieved by assembling or composing objects <ref name="objectcomposition">[http://en.wikipedia.org/wiki/Object_composition Object Composition]</ref>. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large container <ref name="Design Principles">[http://www.artima.com/lejava/articles/designprinciples4.html Design Principles]</ref>. Complex functionality is achieved in this larger container by placing smaller closed containers inside it. Every smaller object has its own independent implementation hidden from the outer container. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</pre>. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
protected Seat seat;
protected Backrest backrest;
protected Leg leg;

Chair() {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another concept related to object composition is that of Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair <ref name="compositionaggregation">[http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-and-aggregation.html Composition and Aggregation]</pre>. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat, backrest and legs do not have any existence without the chair.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. Delegation involved two objects: a delegator who delegates a operation to another object, the delegatee. This can be compared to inheritance where a subclass "defers" request to the parent class for a method which is not overridden in the subclass <ref name="Delegation">[http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf Design Patterns]</ref>. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time, whereas inheritance causes the relationship to be established statically at compile-time. Although, overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases<ref name="Limitations">[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives Limitations and Alternatives]</ref>:

===Problem 1: Multiple Inheritance introduces lot more confusion<ref name="confusions">[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem Diamond Problem]</ref>===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|right|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem <ref name="whitebox">[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html Inheritance breaks Encapsulation]</pre>

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.<ref name="compositionoverinheritance">[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance Composition over Inheritance]</ref>

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

=='''UML Representation'''==
The Unified Modeling Language standard specifies graphical notations for object oriented models. Inheritance is represented using a solid line with a closed, unfilled triangle pointing from the child class to the parent class. For example, following UML represents the inheritance relationship when Dog class subclasses from Pets class.

Composition relationship is represented in UML using a solid line from the parent class to the part class with an unfilled diamond shape on the parent class end. Aggregation has a similar notation with the only difference being that the diamond shape is filled.

==References==
<references/>

CSC/ECE 517 Fall 2012

2012-09-12T02:13:32Z

Narumug4:

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-12T02:08:52Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall look at these concepts one at a time and make the differences clear with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and this subclass will inherit its parent’s attributes and behavior. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
//method definition
}
public void method2() {
//method definition
}
}

class B extends A {
public void method1() {
//method overriding
}
public void method3() {
//method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and method defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
Object composition is an alternative to class inheritance to achieve code reusability. Here, new complex functionality is achieved by assembling or composing objects [http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf]. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large box. Complex functionality is achieved in this larger box by placing smaller closed boxes inside this larger box. Every smaller box has its own independent implementation hidden from the outer box. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another related concept is that if Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat. Backrest and legs do not have an existence without the chair. So, the person object is initialized outside the chair class and can be used inside it with its interface.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance [http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf]. Delegation involved two objects: a delegator who delegates a operation to another object, the delgatee. This can be compared to inheritance where a subclass defers request to the parent class. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time as against Inheritance which causes the relationship to be established statically at compile-time. Although overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives]:

===Problem 1: Multiple Inheritance introduces lot more confusion[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem]===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

[[File:DiamondProblem.png|right|Diamond Problem with Inheritance example.]]

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html]

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance]

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

File:DiamondProblem.png

2012-09-12T02:08:36Z

Narumug4: uploaded a new version of "File:DiamondProblem.png"

File:DiamondProblem.png

2012-09-12T01:52:55Z

Narumug4:

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-12T01:51:44Z

Narumug4:

'''Decomposition, message forwarding, and delegation versus inheritance in OOP'''

=='''Introduction'''==

Inheritance plays an important role in designing reusable object oriented software. In this article we will discuss some alternatives to inheritance to achieve object oriented code reusability. Design techniques like composition, message passing and delegation can be used instead of inheritance to achieve the same goals with more cohesion and less coupling. The basic difference in these approaches lies in the separation of interface and implementation. We shall look at these concepts one at a time and make the differences clear with examples.

=='''Definitions'''==
===Inheritance===
Inheritance is an object oriented programming concept for code reuse. It says that we can define a subclass on a parent class and this subclass will inherit its parent’s attributes and behavior. Consider the following example:

<pre>
class A {
protected int attribute1, attribute2;
public void method1() {
//method definition
}
public void method2() {
//method definition
}
}

class B extends A {
public void method1() {
//method overriding
}
public void method3() {
//method definition
}
}
</pre>

Here, class B is a subclass that inherits the attributes and method defined by its parent A. The subclass inherits the method interface as well as the implementation from its parent. The subclass may define its own attributes and methods or it may provide its own implementation for its parent’s methods. This is called method overriding.

===Composition===
Object composition is an alternative to class inheritance to achieve code reusability. Here, new complex functionality is achieved by assembling or composing objects [http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf]. Unlike inheritance, composition relies on reuse of interface rather than implementation. Consider the new object as a large box. Complex functionality is achieved in this larger box by placing smaller closed boxes inside this larger box. Every smaller box has its own independent implementation hidden from the outer box. Thus composition provides encapsulation in the true sense. This is why composition is also called the black box approach for code reuse. As an example consider a chair class. A chair is made up of a seat, backrest and four legs.

<pre>
public class Seat {
…
}
public class Backrest {
…
}
public class Leg {
…
}
public class Chair {
Seat s = new Seat();
Backrest b = new Backrest();
Leg l = new Leg();
…
}
</pre>

In this example since seat, backrest and legs are components of a chair it is better to use composition instead of inheritance. The seat, backrest and legs class have their own implementation which is hidden from the chair class. These components can be used in the chair class with the help of their defined interface. The chair class can communicate with its component objects through message passing. Thus, code reusability is obtained without caring for the implementation of the component objects.

===Aggregation===
Another related concept is that if Aggregation. Suppose we also use a class Person in the Chair class to represent the person occupying the chair. Then this person is not initialized in the Chair class as a person has an existence irrespective of the chair, whereas the seat. Backrest and legs do not have an existence without the chair. So, the person object is initialized outside the chair class and can be used inside it with its interface.

===Delegation===
Delegation is a way of making composition as powerful for reuse as inheritance [http://www.whigg.cas.cn/resource/program/CPP/201010/P020101022562155422801.pdf]. Delegation involved two objects: a delegator who delegates a operation to another object, the delgatee. This can be compared to inheritance where a subclass defers request to the parent class. The advantage of delegation over inheritance is that delegation allows composition behavior to occur dynamically at run-time as against Inheritance which causes the relationship to be established statically at compile-time. Although overuse or delegation may make the code hard to understand and may invite runtime inefficiencies.

=='''Let us convince ourselves that Inheritance is bad at certain places'''==
Below are the cases[http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives]:

===Problem 1: Multiple Inheritance introduces lot more confusions[http://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem]===
One such is Diamond Problem. Two classes B and C inherit from the same base class A and class D inherits from B and C. If D calls a method defined in class A and implemented very differently in classes B and C.

<pre>
Class A {
virtual print() {
cout << “This is class A”;
}
}
class B : A {
override print() {
cout << “This is class B”;
}
}
class C : A {
override print() {
cout << “This is class C”;
}
}
class D : B, C {
A a = new A();
a.print();
}
</pre>

===Inheritance is link time===
Types are fixed during compile time and super classes cannot be changed dynamically during program execution. Another problem which arises because of static linking is, the changes to super class automatically propagates to the sub-class. In essence inheritance creates a strong coupling. This can be addressed with help of Composition, which allows to change behaviour at runtime.

<pre>
Inheritance:
class Fruit {
}
class Vegetable {
}
class Tomato : Fruit {
}
or
class Tomato : Vegetable{
}

Composition:
class Fruit {
}
class Vegetable {
}
class Tomato {
if(some-criteria) {
Fruit f = new Fruit();
} else {
Vegetable v = new Vegetable();
}
}
</pre>

When inheritance is used class Tomato can either inherit from Fruit or Vegetable, this has to be decide while implementation and cannot be decided during runtime. But when composition is used, based on some condition at run time, Tomato can get behaviour of fruit or vegetable.

===Inheritance is white box===
Inheritance is white box and not black box, since it exposes lot more details than necessary. This violates the OO concept of encapsulation and data hiding. Composition acts as black box and hence solves this problem[http://blog.billyang.me/2009/11/does-inheritance-breaks-encapsulation.html]

===Huge Explosion in the number of Types===
There will be a huge explosion if a new type is created for every possible combination of behaviours, this can be avoided with delegation.

<pre>
Base classes:
class fly {
}
class eat {
}
class talk {
}
class dance {
}

Sub classes:
class human : eat, talk {
}
class birds : fly, eat {
}
class robot : dance, fly {
}
</pre>

In the above example for every possible pair of behaviours there might be class like human can eat and talk and not fly, birds can eat and fly but not dance and robots can dance and fly but not eat. This list can keep growing and might become difficult to manage.

==When to use What==
==='''When to use Inheritance instead of Composition/Aggregation'''===
Composition or Aggregation can always be good instead of Inheritance because it is flexible and behaviour can be changed on the fly. But there are situations where Inheritance might make more sense.

If type B wants to expose the entire interface of type A and type B can be substituted in place of type A - use Inheritance definitely.

<pre>
class Phone {
public dialcall();
public receivecall();
public savecontacts();
}
class SmartPhone : Phone {
}
</pre>

For example, SmartPhone will require and expose all the functionalities of a Phone like dialing a call, receiving a call and saving contacts in phone. Above these basic functionalities might add more functionality. So SmartPhone should be derived from Phone and must not contain Phone.

==='''When to use Composition/Aggregation instead of Inheritance'''===
If type B wants to expose only part of the interface of type A - use Composition/Aggregation.

<pre>
class Dog {
eat();
play();
bark();
}
class Cat : Dog {
bark() {
do nothing
}
}
</pre>

In the above example, class Dog exposes some behaviour and class Cat inherits from Dog. But a cat cannot bark and hence bark method has to be overriden and left empty. Since Cat needs only a part of the behaviour exposed by Dog, it is good to extract out the common functionality and make it a separate interface or class and include in both the classes.[http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance]

==='''When to use Delegation instead of Inheritance'''===
Only when it is needed to copy the functionality and exposing the base class API is not needed then Delegation is the right thing to do.

<pre>
Inheritance:
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack : List {
}

Delegation
class List {
public:
insert_at_front();
insert_at_back();
delete_from_front();
delete_from_back();
insert_at_position();
find_loop();
}
class Stack {
List newlist = new List();
public Push() {
newlist.insert_at_back();
}
public Pop() {
newlist.delete_from_back();
}
}
</pre>

In the above example, Stack is implemented with List, if the Stack class inherits from List class, it gets all the List behaviour like find_loop, insert_at_front, delete_at_front, which is not defined by the Stack ADT and so Stack should not expose these methods. Instead Stack can contain an instance of List and expose just two method needed for a Stack, push and pop. Internally the Push call and Pop call can be redirected to the List class with the help of the List instance.

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-12T01:07:50Z

Narumug4:

CSC/ECE 517 Fall 2012/ch1 1w24 nr

2012-09-12T00:54:12Z

Narumug4: Creating a new page for 1w24 with basic content