Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-12-09T20:05:57Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects. Low coupling means that components such as the client and provider as shown below do not or have very little direct interaction with each other. For example, the client object would not call direclty a method in the provider object, and vise versa. Because of this, we can reuse the provider or client classes, since they are not direclty tied in with each other.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not directly interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. It is easier for the programmers to develop when components are divided, rather than trying to code everything in one monolithic program. When components are divided there is less coupling between components, and it makes it easier to change or add functionality.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h2>Using Indirection to Mediate Several Objects</h2>

Indirection can also be used to centralize the communication between several related objects [7].
 
 
Imagine if we had to make this robot walk. We call LeftFoot to step forward, as well as LeftArm to move up, then LefttArm sends message to RightFoot to step up, which calls RightArm to move up, which calls LeftFoot to step forward, and repeat the process.
 
 
The objects would be calling each other through a series a direct calls and this requires lots of coordination between objects.
 
 
[[Image:EC_7_fig7.jpg]]
 
Trying to make robot walk like this?
 
 
Also, when we add another component, say Head, we would have to change all other component objects in order add another component.
 
 
One way to relieve each class of the burden of having to know which message to pass to the next object, is the use of mediation.
 
 
By using a mediator, in this case, called Controller, we can implement the walking procedure in the controller object and remove the direct calling between component objects.
 
 
[[Image:EC_7_fig8.jpg]]
 
Getting robot to walk using mediator
 
 
The Controller object well now call the components, instead of components calling each other. This relieves each component from the burden of having to know how to interact with each other component. The code becomes much less, and less confusing.
 
 
Also, when we add additional components, we just change the code in Controller.

 

<h2>Advantages of Indirection</h2>

     1. Reduces coupling between objects. 
     2. Code can be reused. 
     3. Code is more extensible and easier to maintain. 
     4. Code is more accessible and understandable. 
     5. Reduces the amount of communications between objects. 
     6. Potentially more secure. Delegation can restrict access to unwanted functionality. 

 

<h2>Disadvantages of Indirection</h2>

     1. Mediator object itself could become too complex. 
     2. Potential performance issues if mediator is poorly implemented or too complex. 

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns] 
[7] Head First Design Patters. Eric Freeman & Elisabeth Freeman. pp. 622-623

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-12-09T19:55:03Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects. Low coupling means that components such as the client and provider as shown below do not or have very little direct interaction with each other. For example, the client object would not call direclty a method in the provider object, and vise versa. Because of this, we can reuse the provider or client classes, since they are not direclty tied in with each other.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not directly interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. It is easier for the programmers to develop when components are divided, rather than trying to code everything in one monolithic program. When components are divided there is less coupling between components, and it makes it easier to change or add functionality.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h2>Using Indirection to Mediate Several Objects</h2>

Indirection can also be used to centralize the communication between several related objects [7].
 
 
Imagine if we had to make this robot walk. We call LeftFoot to step forward, as well as LeftArm to move up, then LefttArm sends message to RightFoot to step up, which calls RightArm to move up, which calls LeftFoot to step forward, and repeat the process.
 
 
The objects would be calling each other through a series a direct calls and this requires lots of coordination between objects.
 
 
[[Image:EC_7_fig7.jpg]]
 
Trying to make robot walk like this?
 
 
Also, when we add another component, say Head, we would have to change all other component objects in order add another component.
 
 
One way to relieve each class of the burden of having to know which message to pass to the next object, is the use of mediation.
 
 
By using a mediator, in this case, called Controller, we can implement the walking procedure in the controller object and remove the direct calling between component objects.
 
 
[[Image:EC_7_fig8.jpg]]
 
Getting robot to walk using mediator
 
 
The Controller object well now call the components, instead of components calling each other. This relieves each component from the burden of having to know how to interact with each other component. The code becomes much less, and less confusing.
 
 
Also, when we add additional components, we just change the code in Controller.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns] 
[7] Head First Design Patters. Eric Freeman & Elisabeth Freeman. pp. 622-623

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-12-09T19:52:33Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects. Low coupling means that components such as the client and provider as shown below do not or have very little direct interaction with each other. For example, the client object would not call direclty a method in the provider object, and vise versa. Because of this, we can reuse the provider or client classes, since they are not direclty tied in with each other.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not directly interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. It is easier for the programmers to develop when components are divided, rather than trying to code everything in one monolithic program. When components are divided there is less coupling between components, and it makes it easier to change or add functionality.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h2>Using Indirection to Mediate Several Objects</h2>

Indirection can also be used to centralize the communication between several related objects [7].
 
 
Imagine if we had to make this robot walk. We call LeftFoot to step forward, as well as LeftArm to move up, then LefttArm sends message to RightFoot to step up, which calls RightArm to move up, which calls LeftFoot to step forward, and repeat the process.
 
 
The objects would be calling each other through a series a direct calls and this requires lots of coordination between objects.
 
 
[[Image:EC_7_fig7.jpg]]
 
Trying to make robot walk like this?
 
 
Also, when we add another component, say Head, we would have to change all other component objects in order add another component.
 
 
One way to relieve each class of the burden of having to know which message to pass to the next object, is the use of mediation.
 
 
By using a mediator, in this case, called Controller, we can implement the walking procedure in the controller object and remove the direct calling between component objects.
 
 
[[Image:EC_7_fig8.jpg]]
 
Getting robot to walk using mediator
 
 
The Controller object well now call the components, instead of components calling each other. This relieves each component from the burden of having to know how to interact with each other component. The code becomes much less, and less confusing.
 
 
Also, when we add additional components, we just change the code in Controller.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns]

File:EC 7 fig8.jpg

2010-12-09T19:45:54Z

Jechen:

File:EC 7 fig7.jpg

2010-12-09T19:45:44Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-12-09T19:17:48Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects. Low coupling means that components such as the client and provider as shown below do not or have very little direct interaction with each other. For example, the client object would not call direclty a method in the provider object, and vise versa. Because of this, we can reuse the provider or client classes, since they are not direclty tied in with each other.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not directly interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. It is easier for the programmers to develop when components are divided, rather than trying to code everything in one monolithic program. When components are divided there is less coupling between components, and it makes it easier to change or add functionality.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns]

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-12-09T18:52:22Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects. Low coupling means that components such as the client and provider as shown below do not or have very little direct interaction with each other. For example, the client object would not call direclty a method in the provider object, and vise versa. Because of this, we can reuse the provider or client classes, since they are not direclty tied in with each other.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns]

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:31:12Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13 
[6] [http://www.icaen.uiowa.edu/~kuhl/SoftEng/Slides10.pdf More GRASP Patterns]

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:29:29Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change [6]. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:26:37Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14 
[5] Dr. Gehringer. Lecture notes 10. pp 12-13

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:26:23Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

 

<h1>Sources</h1>
[1] Dale Skrien. Object-Oriented Design Using Java. pp. 196-197 
[2] [http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29 Wikipedia - GRASP] 
[3] [http://en.wikipedia.org/wiki/Delegation_pattern Wikipedia - Delegation Pattern] 
[4] Dave Thomas. Agile Web Development with Rails. pp. 11-14
[5] Dr. Gehringer. Lecture notes 10. pp 12-13

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:19:33Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.

 

<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:18:57Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {

private RobotController rc;

public SafeRobotController {
rc = new RobotController();
}

void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:16:45Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig6.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig5.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:14:56Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.

 

<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:14:01Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.

 

<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:12:50Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {

RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}
}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.


<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:11:37Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.

 

<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {
RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}

}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.


<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:11:02Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.

 

<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.


<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {
RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}

}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.


<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:10:07Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.
 


<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.


<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {
RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}

}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.


<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:08:29Z

Jechen:

<h1>Introduction to Design Patterns</h1>

A design pattern is a type of technique that developers use to create good software design. There are many design patterns available, and they share common benefits. The benefits of design patterns include [1] :
 
 
     1. Code is more accessible and understandable. 
     2. Use of common vocabulary to help collaboration among developers. 
     3. Helps people understand the system more quickly. 
     4. Easier to modify system. 


<h2>GRASP</h2>

GRASP stands for General Responsibility Assignment Software Patterns and consists of several design patterns for assigning responsibility and relationships between classes and objects in object-oriented design.
 
 
Some of the patterns in GRASP include Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, and Protected Variations [2].
 
 
In this article, we will focus on the Indirection Pattern.


<h1>The Indirection Pattern</h1>

The Indirection Pattern supports low coupling and code reuse by using a mediator object in between two objects.
 
 
A very simple diagram below illustrates the relationship between objects in the indirection pattern.
 
 
[[Image:EC_7_fig1.jpg]]
 
The relationship between classes in indirection pattern.
 
 
In the indirection pattern, a mediator class acts as a proxy in between the client and provider classes. The client interfaces with the mediator, not to the provider. The client accesses functionality from the provider through the mediator. Therefore, the relationship between the client and provider is indirect.
 
 
The indirection pattern is seen all of the time. Anytime the programmer accesses an API, be it for operating system call, graphics library call, the programmer is interfacing with a mediator that provides functionality on behalf of the client to some lower-level hardware functionality provided by the operating system or graphics library, etc.
 
 
A simple example of the indirection pattern is illustrated below.


<h2>Example of Indirection Pattern</h2>

Let's say we have a talking robot, and the functionality to get the robot to say a specified string has already been implemented in the code below.
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}
}
</pre>
 
 
We want to create another class that has methods to say common phrases like “hello” and “goodbye”.
 
 
<pre>
class RobotPhrases {
RobotController r = new RobotController();

void sayHello() {
r.say(“Hello”);
}

void sayGoodbye() {
r.say(“Goodbye”);
}
}
</pre>
 
 
In the main function, we would do the following:
 
 
<pre>
public class Main {
public static void main(String[] args) {
RobotPhrases rp = new RobotPhrases();
rp.sayHello();
rp.sayGoodbye();
}

}
</pre>
 
 
[[Image:EC_7_fig2.jpg]]
 
The RobotPhrases object instantiates a RobotController object to act as a mediator to access functionality in RobotController.
 
 
From the main class, it appears that our new RobotPhrases class has implemented the functionality to make the robot speak the specific words, when in fact, we have used a mediator object to do the work. Basically, we have passed of the duty to someone/something else [3].
 
 
Specifically, the mediator object is the RobotController r object created in the RobotPhrases that mediates the action between the two classes.
 
 
The advantage of the indirection pattern in this case, is that the RobotPhrases class is much easier to implement since we did not have to put complex, low-level robot code in the class. Also, when the speaking functionality of the robot changes, we only need to modify the say function in RobotController and not in the sayHello and sayGoodbye functions in the new class. This makes maintainability and code reuse much greater.


<h2>Another Example: Ruby on Rails</h2>

Another example of where the indirection pattern is used is the system design architecture used for web development with Ruby on Rails.
 
 
Rails uses the MVC architecture, where applications are separated into three components: model, view, and controller [4].
 
 
To briefly describe the tasks of the components [4]:
 
 
Model
 
 
Responsible for maintaining state of application. Includes data storage, generally in the form a database.
 
 
View
 
 
Provides the user interface for input and output.
 
 
Controller
 
 
Orchestrates input from view to model and provide output to view.
 
 
[[Image:EC_7_fig3.jpg]]
 
The MVC architecture used in Rails
 
 
Let's assume that we implement an online music store using Rails and the MVC architecture. A typical use case is illustrated below.
 
 
     1. User enters http://my.url.com and view is displayed. 
     2. User enters “beatles” in search box. 
     3. Search parameter is passed to controller. 
     4. Controller accesses songs database in Model to search for query. 
     5. Model returns result to Controller. 
     6. Controller creates view to display results. 
 
 
From this use case, the separation between view and model is illustrated. The Model does not interact with the View, and the View does not directly interact with the Model. The Controller acts as a mediator between View and Model.
 
 
The advantage of this approach is extensibility and maintainability. When View and Models are separated, they can be reused again. Whereas, if the Model and View where combined, the implementation could only be used for this application.
 
 
For example, if we wanted to create an online bookstore, we could reuse the same View components from the online music store, with some minimal changes. On the other hand, if we did not use MVC and the indirection pattern, and the View was tied in with the music Model, we probably could not easily reuse the code.


<h2>Indirection through Delegation</h2>

Indirection can also be achieved through the use of delegation.
 
 
To see this, lets assume that we are building a robot and need to implement robot functions. An existing class called RobotController already exists and has the functions we desire and then some that we don't want.
 
 
[[Image:EC_7_fig4.jpg]]
 
UML diagram for existing RobotController class
 
 
<pre>
class RobotController {
void say(String s) {
// Some complex code for robot to say 's'
}

void walk() {
// Some complex code to walk
}

void grab() {
// Some complex code to grab nearest item
}

void selfDestruct()
// Code to self destruct robot
}

void fireWeapon()
// Code to fire weapon
}
}
</pre>
 
 
The RobotController class contains all of the functionality that we desire, except we don't want selfDestruct() nor fireWeapon() methods!
 
 
One solution would be to copy over this class to create a new class, and just delete the unwanted methods. However, this involves copying over a lot of complex code, and if that code were to change, we would need to change it in the new class as well.
 
 
Another solution would be to extend this class and just override the unwanted methods with error message or simply just do nothing and return. For example, the following implementation could be done.
 
 
<pre>
class SafeRobotController extends RobotController {
void selfDestruct()
// Don't want this, so just return
return;
}

void fireWeapon()
// Don't want this, so just return
return;
}
}
</pre>
 
 
[[Image:EC_7_fig5.jpg]]
 
Extending and overriding unsafe methods in RobotController
 
 
This seems like an elegant solution, however, what happens when someone adds more functionality to RobotController such as smashObject() or becomeSelfAware(). Unfortunately, the SafeRobotController will inherit these methods.
 
 
[[Image:EC_7_fig6.jpg]]
 
Will SafeRobotContoller still be “safe” when the RobotController class changes to the above?
 
 
Another solution is to use indirection and not directly involve the RobotController class. Using delegation, we can isolate the class and selectively implement the desired functionality. The code below illustrates how this can be achieved.
 
 
<pre>
class SafeRobotController {
private RobotController rc;
public SafeRobotController {
rc = new RobotController();
}
void say(String s) {
rc.say(s);
}

void walk() {
rc.walk();
}

void grab() {
rc.grab();
}
}
</pre>
 
 
Here, the SafeRobotController instantiates a RobotController object and calls only the desired methods. Even if some evil programmer adds ill methods to RobotController, they cannot be accessed by SafeRobotController.
 
 
Essentially, we have added indirection between SafeRobotController and RobotController through the use of a mediator object.


<h1>Summary</h1>

The indirection pattern is a powerful design pattern that helps the software designer implement good design by maximizing code reuse and extensibility. In the examples shown above, indirection reduces the coupling between classes or components that are likely to change. By doing so, one could reuse or extend one component without having to affect the other.

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T03:00:31Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:56:42Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:52:53Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:49:18Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:42:41Z

Jechen:

File:EC 7 fig6.jpg

2010-11-23T02:40:35Z

Jechen:

File:EC 7 fig5.jpg

2010-11-23T02:40:22Z

Jechen:

File:EC 7 fig4.jpg

2010-11-23T02:40:13Z

Jechen:

File:EC 7 fig3.jpg

2010-11-23T02:40:03Z

Jechen:

File:EC 7 fig2.jpg

2010-11-23T02:39:53Z

Jechen:

File:EC 7 fig1.jpg

2010-11-23T02:39:40Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:32:59Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:30:53Z

Jechen:

CSC/ECE 517 Fall 2010/ch7 7d EC

2010-11-23T02:27:53Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:33:06Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.

 

<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
    // Implementation of generic bike class 
    // ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
    // inherit generic bike components 
    // add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
    // inherit generic bike components 
    // add narrow tires, drop-style handlebars, etc. 
} 
</code>

 

<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
    // frame of a bike 
} 
 
class Wheels { 
    // wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
    // create bike by putting together frame and wheels 
} 
 
</code>

 

<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.

 

<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

 
<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

 
<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

 
<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
    String makeSound () { 
        return "silence" 
    } 
} 
 
class Cow: public Animal { 
    String makeSound() { 
        return "moo"; // redefine method 
    } 
} 
 
class Duck: public Animal { 
    String makeSound() { 
        return "quack"; // redefine method 
    } 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
    // automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
    String makeSound () { 
        return "silence" 
    } 
} 
 
class Cow: public virtual Animal { 
    String makeSound() { 
        return "moo"; // redefine method 
    } 
} 
 
class Duck: public virtual Animal { 
    String makeSound() { 
        return "quack"; // redefine method 
    } 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
    // automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 

 
<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

 
<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

 
<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
    void shootWeb(); 
    void climbWalls(); 
} 
 
interface Man { 
    void talk(); 
    void run(); 
} 
 
public class Spiderman implements Spider, Man { 
    public void shootWeb() {...} 
    public void climbWalls() {...} 
    public void talk() {...} 
    public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
    void shootWeb { ... } 
    void climbWalls { ... } 
} 
 
public class Man { 
    void talk() { ... } 
    void run() { ... } 
} 
 
public class Spiderman { 
    Spider s; 
    Man m; 
 
    // Spiderman specific stuff 
} 
 
public class Venom { 
    Spider s; 
 
    // Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

 
<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
    def shootWeb() 
        // ... 
    end 
    def climbWalls() 
        // ... 
    end 
end 
 
module Man 
    def talk() 
        // ... 
    end 
    def run() 
        // ... 
    end 
end 
 
class Spiderman 
    include Spider 
    include Man 
    // ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
 
     1. It is not a class 
     2. It cannot be instantiated 
     3. It can be mixed into a class 
 
 
When modules are mixed into a class8,
 
     1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man"
 
     2. Multiple modules can be mixed-in to a class. 

 
<h1>References</h1>

1. Object-Oriented Design Using Java. Dale Skrien. 2009. pp. 10-30
 
2. [http://en.wikipedia.org/wiki/Multiple_inheritance Wikipedia - Multiple Inheritance]
 
3. CSC517 Lec. 9 Notes. Dr. Gehringer. 2010
 
4. [http://en.wikipedia.org/wiki/Diamond_problem Wikipedia - Diamond Problem]
 
5. Beginning Visual C++. Ivor Horton. 1998. pp. 422-424.
 
6. [http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html JavaWorld - Designing with interfaces]
 
7. [http://www.java2s.com/Code/Java/Language-Basics/Implementmultipleinterfaces.htm Implement multiple interfaces]
 
8. [http://www.rubyfleebie.com/an-introduction-to-modules-part-2/ An Introduction to modules]

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:29:36Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.

 

<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
   &nbsp// Implementation of generic bike class 
   &nbsp// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
   &nbsp// inherit generic bike components 
   &nbsp// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
    // inherit generic bike components 
    // add narrow tires, drop-style handlebars, etc. 
} 
</code>

 

<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
    // frame of a bike 
} 
 
class Wheels { 
    // wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
    // create bike by putting together frame and wheels 
} 
 
</code>

 

<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.

 

<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

 
<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

 
<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

 
<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
    String makeSound () { 
        return "silence" 
    } 
} 
 
class Cow: public Animal { 
    String makeSound() { 
        return "moo"; // redefine method 
    } 
} 
 
class Duck: public Animal { 
    String makeSound() { 
        return "quack"; // redefine method 
    } 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
    // automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
    String makeSound () { 
        return "silence" 
    } 
} 
 
class Cow: public virtual Animal { 
    String makeSound() { 
        return "moo"; // redefine method 
    } 
} 
 
class Duck: public virtual Animal { 
    String makeSound() { 
        return "quack"; // redefine method 
    } 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
    // automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 

 
<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

 
<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

 
<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
    void shootWeb(); 
    void climbWalls(); 
} 
 
interface Man { 
    void talk(); 
    void run(); 
} 
 
public class Spiderman implements Spider, Man { 
    public void shootWeb() {...} 
    public void climbWalls() {...} 
    public void talk() {...} 
    public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
    void shootWeb { ... } 
    void climbWalls { ... } 
} 
 
public class Man { 
    void talk() { ... } 
    void run() { ... } 
} 
 
public class Spiderman { 
    Spider s; 
    Man m; 
 
    // Spiderman specific stuff 
} 
 
public class Venom { 
    Spider s; 
 
    // Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

 
<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
    def shootWeb() 
        // ... 
    end 
    def climbWalls() 
        // ... 
    end 
end 
 
module Man 
    def talk() 
        // ... 
    end 
    def run() 
        // ... 
    end 
end 
 
class Spiderman 
    include Spider 
    include Man 
    // ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
 
     1. It is not a class 
     2. It cannot be instantiated 
     3. It can be mixed into a class 
 
 
When modules are mixed into a class8,
 
     1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man"
 
     2. Multiple modules can be mixed-in to a class. 

 
<h1>References</h1>

1. Object-Oriented Design Using Java. Dale Skrien. 2009. pp. 10-30
 
2. [http://en.wikipedia.org/wiki/Multiple_inheritance Wikipedia - Multiple Inheritance]
 
3. CSC517 Lec. 9 Notes. Dr. Gehringer. 2010
 
4. [http://en.wikipedia.org/wiki/Diamond_problem Wikipedia - Diamond Problem]
 
5. Beginning Visual C++. Ivor Horton. 1998. pp. 422-424.
 
6. [http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html JavaWorld - Designing with interfaces]
 
7. [http://www.java2s.com/Code/Java/Language-Basics/Implementmultipleinterfaces.htm Implement multiple interfaces]
 
8. [http://www.rubyfleebie.com/an-introduction-to-modules-part-2/ An Introduction to modules]

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:23:57Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.

 

<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
     // Implementation of generic bike class 
// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
// inherit generic bike components 
// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
// inherit generic bike components 
// add narrow tires, drop-style handlebars, etc. 
} 
</code>

 

<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
// frame of a bike 
} 
 
class Wheels { 
// wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
// create bike by putting together frame and wheels 
} 
 
</code>

 

<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.

 

<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

 
<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

 
<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

 
<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public virtual Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public virtual Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 

 
<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

 
<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

 
<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
void shootWeb(); 
void climbWalls(); 
} 
 
interface Man { 
void talk(); 
void run(); 
} 
 
public class Spiderman implements Spider, Man { 
public void shootWeb() {...} 
public void climbWalls() {...} 
public void talk() {...} 
public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
void shootWeb { ... } 
void climbWalls { ... } 
} 
 
public class Man { 
void talk() { ... } 
void run() { ... } 
} 
 
public class Spiderman { 
Spider s; 
Man m; 
 
// Spiderman specific stuff 
} 
 
public class Venom { 
Spider s; 
 
// Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

 
<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
def shootWeb() 
// ... 
end 
def climbWalls() 
// ... 
end 
end 
 
module Man 
def talk() 
// ... 
end 
def run() 
// ... 
end 
end 
 
class Spiderman 
include Spider 
include Man 
// ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
 
1. It is not a class 
2. It cannot be instantiated 
3. It can be mixed into a class 
 
 
When modules are mixed into a class8,
 
1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man"
 
2. Multiple modules can be mixed-in to a class. 

 
<h1>References</h1>

1. Object-Oriented Design Using Java. Dale Skrien. 2009. pp. 10-30
 
2. [http://en.wikipedia.org/wiki/Multiple_inheritance Wikipedia - Multiple Inheritance]
 
3. CSC517 Lec. 9 Notes. Dr. Gehringer. 2010
 
4. [http://en.wikipedia.org/wiki/Diamond_problem Wikipedia - Diamond Problem]
 
5. Beginning Visual C++. Ivor Horton. 1998. pp. 422-424.
 
6. [http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html JavaWorld - Designing with interfaces]
 
7. [http://www.java2s.com/Code/Java/Language-Basics/Implementmultipleinterfaces.htm Implement multiple interfaces]
 
8. [http://www.rubyfleebie.com/an-introduction-to-modules-part-2/ An Introduction to modules]

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:20:52Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.

 

<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
// Implementation of generic bike class 
// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
// inherit generic bike components 
// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
// inherit generic bike components 
// add narrow tires, drop-style handlebars, etc. 
} 
</code>

 

<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
// frame of a bike 
} 
 
class Wheels { 
// wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
// create bike by putting together frame and wheels 
} 
 
</code>

 

<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.

 

<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

 
<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

 
<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

 
<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public virtual Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public virtual Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 

 
<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

 
<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

 
<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
void shootWeb(); 
void climbWalls(); 
} 
 
interface Man { 
void talk(); 
void run(); 
} 
 
public class Spiderman implements Spider, Man { 
public void shootWeb() {...} 
public void climbWalls() {...} 
public void talk() {...} 
public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
void shootWeb { ... } 
void climbWalls { ... } 
} 
 
public class Man { 
void talk() { ... } 
void run() { ... } 
} 
 
public class Spiderman { 
Spider s; 
Man m; 
 
// Spiderman specific stuff 
} 
 
public class Venom { 
Spider s; 
 
// Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

 
<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
def shootWeb() 
// ... 
end 
def climbWalls() 
// ... 
end 
end 
 
module Man 
def talk() 
// ... 
end 
def run() 
// ... 
end 
end 
 
class Spiderman 
include Spider 
include Man 
// ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
 
1. It is not a class 
2. It cannot be instantiated 
3. It can be mixed into a class 
 
 
When modules are mixed into a class8,
 
1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man"
 
2. Multiple modules can be mixed-in to a class. 

 
<h1>References</h1>

1. Object-Oriented Design Using Java. Dale Skrien. 2009. pp. 10-30
 
2. [http://en.wikipedia.org/wiki/Multiple_inheritance Wikipedia - Multiple Inheritance]
 
3. CSC517 Lec. 9 Notes. Dr. Gehringer. 2010
 
4. [http://en.wikipedia.org/wiki/Diamond_problem Wikipedia - Diamond Problem]
 
5. Beginning Visual C++. Ivor Horton. 1998. pp. 422-424.
 
6. [http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html JavaWorld - Designing with interfaces]
 
7. [http://www.java2s.com/Code/Java/Language-Basics/Implementmultipleinterfaces.htm Implement multiple interfaces]
 
8. [http://www.rubyfleebie.com/an-introduction-to-modules-part-2/ An Introduction to modules]

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:16:24Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.


<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
// Implementation of generic bike class 
// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
// inherit generic bike components 
// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
// inherit generic bike components 
// add narrow tires, drop-style handlebars, etc. 
} 
</code>


<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
// frame of a bike 
} 
 
class Wheels { 
// wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
// create bike by putting together frame and wheels 
} 
 
</code>


<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.


<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public virtual Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public virtual Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 


<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
void shootWeb(); 
void climbWalls(); 
} 
 
interface Man { 
void talk(); 
void run(); 
} 
 
public class Spiderman implements Spider, Man { 
public void shootWeb() {...} 
public void climbWalls() {...} 
public void talk() {...} 
public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
void shootWeb { ... } 
void climbWalls { ... } 
} 
 
public class Man { 
void talk() { ... } 
void run() { ... } 
} 
 
public class Spiderman { 
Spider s; 
Man m; 
 
// Spiderman specific stuff 
} 
 
public class Venom { 
Spider s; 
 
// Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
def shootWeb() 
// ... 
end 
def climbWalls() 
// ... 
end 
end 
 
module Man 
def talk() 
// ... 
end 
def run() 
// ... 
end 
end 
 
class Spiderman 
include Spider 
include Man 
// ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
 
1. It is not a class 
2. It cannot be instantiated 
3. It can be mixed into a class 
 
 
When modules are mixed into a class8,
 
1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man"
 
2. Multiple modules can be mixed-in to a class. 

 
<h1>References</h1>

1. Object-Oriented Design Using Java. Dale Skrien. 2009. pp. 10-30
 
2. [http://en.wikipedia.org/wiki/Multiple_inheritance Wikipedia - Multiple Inheritance]
 
3. CSC517 Lec. 9 Notes. Dr. Gehringer. 2010
 
4. [http://en.wikipedia.org/wiki/Diamond_problem Wikipedia - Diamond Problem]
 
5. Beginning Visual C++. Ivor Horton. 1998. pp. 422-424.
 
6. [http://www.javaworld.com/javaworld/jw-12-1998/jw-12-techniques.html JavaWorld - Designing with interfaces]
 
7. [http://www.java2s.com/Code/Java/Language-Basics/Implementmultipleinterfaces.htm Implement multiple interfaces]
 
8. [http://www.rubyfleebie.com/an-introduction-to-modules-part-2/ An Introduction to modules]

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:10:14Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.


<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
// Implementation of generic bike class 
// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
// inherit generic bike components 
// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
// inherit generic bike components 
// add narrow tires, drop-style handlebars, etc. 
} 
</code>


<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
// frame of a bike 
} 
 
class Wheels { 
// wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
// create bike by putting together frame and wheels 
} 
 
</code>


<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.


<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
</code>
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public virtual Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public virtual Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 


<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
void shootWeb(); 
void climbWalls(); 
} 
 
interface Man { 
void talk(); 
void run(); 
} 
 
public class Spiderman implements Spider, Man { 
public void shootWeb() {...} 
public void climbWalls() {...} 
public void talk() {...} 
public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
void shootWeb { ... } 
void climbWalls { ... } 
} 
 
public class Man { 
void talk() { ... } 
void run() { ... } 
} 
 
public class Spiderman { 
Spider s; 
Man m; 
 
// Spiderman specific stuff 
} 
 
public class Venom { 
Spider s; 
 
// Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
def shootWeb() 
// ... 
end 
def climbWalls() 
// ... 
end 
end 
 
module Man 
def talk() 
// ... 
end 
def run() 
// ... 
end 
end 
 
class Spiderman 
include Spider 
include Man 
// ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
1. It is not a class 
2. It cannot be instantiated 
3. It can be mixed into a class 
 
 
When modules are mixed into a class8, 
1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man" 
2. Multiple modules can be mixed-in to a class.

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T20:02:14Z

Jechen:

<h1>What is inheritance?</h1>


Inheritance is a functionality of object-oriented programming where a subclass obtains the contents and functionality of its superclass.

 
 

Instead of duplicating a class, a user can create a class that is a subclass of another class, inherit all of its functionality, and just add additional functionality.

 
 

For example, if the class "Bike" already exists and we wanted to create specific type of bicycle such as "MountainBike" or "RoadBike", we could just create classes that inherit from the "Bike" class and add the additional functionality we need.

 
 

[[Image:EC_fig1.jpg]]

 
Figure 1: Simple case of inheritance

 
 

The use of inheritance is convenient because we did not have to duplicate code to create a new subclass and increases code re-usability1. Also, if changes are made to the superclass, those changes will be reflected in the subclasses as well.


<h2>Single Inheritance</h2>


For the example above, where a subclass inherits from a single parent class, this is called single inheritance.

 
 

Object-oriented languages including Java, support single inheritance. A Java implementation would appear as below.

 
 

<code>
public class Bike { 
// Implementation of generic bike class 
// ie. frame, wheels 
} 
 
public class MountainBike extends Bike { 
// inherit generic bike components 
// add shocks, fat tires, etc. 
} 
 
public class RoadBike extends Bike { 
// inherit generic bike components 
// add narrow tires, drop-style handlebars, etc. 
} 
</code>


<h2>Multiple Inheritance</h2>

To enhance the concept of code re-usability even further, a user may wish to inherit from multiple parent classes. For example, the class "Bike" could have been made up from two classes called "Frame" and "Wheels".
 
 
[[Image:EC_fig2.jpg]]
 
Figure 2: Case of multiple inheritance
 
 
The case where a subclass inherits from multiple parent classes is called multiple inheritance. This feature is not supported in all objected oriented languages.
 
 
Languages that support multiple inheritance include C++, Python, Perl, Lisp, Tcl2, and Ruby (with the use of mixins).
 
 
The C++ implementation of the example is shown below.
 
 
<code>
class Frame { 
// frame of a bike 
} 
 
class Wheels { 
// wheels of a bike 
} 
 
class Bike: public Frame, public Wheels 
// create bike by putting together frame and wheels 
} 
 
</code>


<h1>Advantages of Multiple Inheritance</h1>

Multiple inheritance allows the programmer to 'mix-and-match' elements from several classes to form a new class. This saves effort from the programmer by not having to duplicate code and modify code when parent classes are changed. For more complicated hierarchies, this feature can quite useful.
 
 
Consider the case below where we have "Engine", "Chassis", and "Body" parent classes and two subclasses "Sedan" and "Truck".
 
 
The "Sedan" class is a sedan and needs an engine, chassis, and body so it inherits from all three parent classes. Same can be applied for the "Truck" class. The "Sedan" and "Truck" inherits all three components and they can modify them to suit their needs. The sedan could have a longer body to increase passenger room, the truck overrides body for an open cab, and so on.
 
 
Assume that we need polymorphic functionality. For example, we need to be able to run the following code:
 
 
<code>
Sedan s = new Sedan();
</code>
 
 
Then we pass object 's' to a method somewhere requiring an "Engine" type such as
 
 
<code>
int testEngine(Engine e);
</code>
 
 
Since our sedan has an engine we want to do:
 
 
<code>
testEngine(s);
</code>
 
 
Let's say later, we want to create a push-type lawnmower. The lawnmower does not need the chassis or body implementations, but needs an engine so we just inherit from the "Engine" class.
 
 
[[Image:EC_fig3.jpg]]
 
Figure 3: Multiple inheritance allows more flexible hierarchies.
 
 
With single inheritance, the structure illustrated above would not be possible. Since a subclass cannot inherit from multiple parent classes, the programmer would probably have to combine all three "Engine", "Chassis", and "Body" classes into a single class, perhaps called "Assembly". Then the "Sedan" and "Truck" classes would inherit from this combined class.
 
 
[[Image:EC_fig4.jpg]]
 
Figure 4: Single inheritance limits hierarchy.
 
 
The "Lawnmower" class now posses a dilemma. Should we inherit from the "Assembly" class and get a lot of functionality we don't need and possibly introduce unwanted behavior. Or should the code for the engine be duplicated from the "Assembly" class and copied into the "Lawnmower" classes. What happens when engine specifications change, we would need to modify engine code in two places?
 
 
Therefore, as the example demonstrates the structure for single inheritance is more constrained.


<h1>Disadvantages of Multiple Inheritance</h1>

Although multiple inheritance gives programmers more flexibility in class hierarchies and 'mix-and-match' implementation, one would think that it should be included in all object-oriented languages.
 
 
The reality is that several implementation issues keep it from being incorporated into some languages.
 
 
Some key issues include name and method collision3, the diamond problem4, and conceptual difficulties and understandability problems3.

<h2>Name collision</h2>

A subclass that inherits from several parents classes with the same variable names will have name collisions.
 
 
[[Image:EC_fig5.jpg]]
 
Figure 5: Which x value will print_x() method print?
 
 
It is unclear which value of 'x' would be printed. Different languages and compilers will handle this differently.

<h2>Method collision</h2>

Similar to name collision, when a subclass inherits from the several parents with the same method names, method collision will occur.
 
 
[[Image:EC_fig6.jpg]]
 
Figure 6: Which show() method will Package inherit?

<h2>The Diamond Problem</h2>

The diamond problem occurs when the direct base classes are themselves derived from another class5. This can be illustrated in the hierarchy below. The pattern forms a diamond shape, hence the name of the problem.
 
 
[[Image:EC_fig7.jpg]]
 
Figure 7: What sound should the CowDuckHybird make?
 
 
Let's define two classes called "Cow" and "Duck". They both inherit from "Animal". The makeSound() method is inherited in both "Cow" and "Duck" classes. The "Cow" class defines the method to return "moo", while the "Duck" class redefines the method to return "quack".
 
 
Let's assume that through some strange breeding, a cow and duck breed to create a "CowDuckHybird" classes which inherits from both "Cow" and "Duck" parents. When the makeSound() method is called on a "CowDuckHybrid" object, what sound will make?
 
 
In a multiple inheritance supporting language such as C++, the "CowDuckHybrid" class would implement both makeSound() methods, and the programmer has to explicitly specify which one to use.
 
 
The code implementation in C++ illustrates this kind of problem below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // illegal statement - compiler will complain 
a.Cow::makeSound(); // outputs "moo" 
a.Duck::makeSound() // outputs "quack" 
 
 
In C++, the programmer must explicitly specify which duplicate method to run. If not, the compiler will throw an error.
 
 
There is also additional functionally in C++ to address the issue of diamond-like hierarchies. The concept of virtual base classes can make a class appear to be virtual or transparent. By making the two intermediate classes "Duck" and "Cow" virtual, we tell the compiler not to make duplicate variables or methods in "CowDuckHybrid" or any classes derived from the two virtual classes5.
 
 
The implementation with virtual classes is shown below.
 
 
<code>
class Animal { 
String makeSound () { 
return "silence" 
} 
} 
 
class Cow: public virtual Animal { 
String makeSound() { 
return "moo"; // redefine method 
} 
} 
 
class Duck: public virtual Animal { 
String makeSound() { 
return "quack"; // redefine method 
} 
} 
 
class CowDuckHybrid: public Cow, public Duck { 
// automatically inherit makeSound() from Cow and Duck 
} 
 
// Main code 
Animal a; 
a.makeSound(); // now legal, outputs "silence" 
</code>
 

<h2>Conceptual Difficulties</h2>

For large projects, where there are several layers of classes and inheritance from many classes, the amount of conflicts can become high and resolving those conflicts can become very tedious. In languages such as C++, where multiple inheritance is supported, the programmer must explicitly indicate which parent class method or variable to use, or resolve the conflict by using the virtual keyword functionality. This, however, requires the programmer to trace back to the parent classes to determine what course of action to take.
 
 
Without good organization of the classes and understanding of how they are organized, multiple inheritance can become more trouble than it is worth.

<h1>Alternatives to Multiple Inheritance</h1>

Many object-oriented languages do not use multiple inheritance for the reasons mentioned above. One of those languages is Java. Part of the philosophy of the Java language is to be simple and ease of use, and the creators of Java decided not to have support for multiple inheritance.
 

<h2>Alternative in Java</h2>

Java can simulate multiple inheritance through the use of multiple interfaces6,7. For example, the hierarchy below can be implemented in Java.
 
 
[[Image:EC_fig8.jpg]]
 
Figure 8: Implementing multiple inheritance in Java
 
 
<code>
interface Spider { 
void shootWeb(); 
void climbWalls(); 
} 
 
interface Man { 
void talk(); 
void run(); 
} 
 
public class Spiderman implements Spider, Man { 
public void shootWeb() {...} 
public void climbWalls() {...} 
public void talk() {...} 
public void run() {...} 
} 
 
// Main code 
Spider s = new Spiderman(); // all of these statements are valid 
Man m = new Spiderman(); 
Spiderman sm = new Spiderman(); 
</code>
 
 
Note that in this implementation, we would have to implement the "Spider" and "Man" methods in the "Spiderman" class. We cannot include code in the interface, as this violates the concept of interfaces in Java. We loose code re-usability, but persevered polymorphic relationship. If we created another class called "Venom" and implemented "Spider" class, we would have to duplicate the code.
 
 
On the other hand, if we don't care about polymorphism and just don't want to duplicate code, we can just compost the code like the following.
 
 
<code>
public class Spider { 
void shootWeb { ... } 
void climbWalls { ... } 
} 
 
public class Man { 
void talk() { ... } 
void run() { ... } 
} 
 
public class Spiderman { 
Spider s; 
Man m; 
 
// Spiderman specific stuff 
} 
 
public class Venom { 
Spider s; 
 
// Venom specific stuff 
} 
</code>
 
 
Here both "Spiderman" and "Venom" can reuse the "Spider" class code without having to implement it twice. However, "Spiderman" cannot be considered a "Spider" nor a "Man".
 
 
Both solutions shown are not really multiple inheritance in the true sense, but they can get the job done, depending on the specifications of the design.

<h2>Modules and Mixins</h2>

Ruby can simulate multiple inheritance using modules. In Ruby the code appears as follows.
 
 
<code>
module Spider 
def shootWeb() 
// ... 
end 
def climbWalls() 
// ... 
end 
end 
 
module Man 
def talk() 
// ... 
end 
def run() 
// ... 
end 
end 
 
class Spiderman 
include Spider 
include Man 
// ... 
end 
</code>
 
 
In Ruby, the module code is simply "mixed in" to the specified class, basically a copy and paste function.
 
 
Here are some key rules to modules in Ruby.8
1. It is not a class 
2. It cannot be instantiated 
3. It can be mixed into a class 
 
 
When modules are mixed into a class8, 
1. There is no hierarchy. Even though we included "Spider" and "Man" in class "Spiderman", "Spiderman" object cannot be polymorphized into "Spider" nor "Man". That is, "Spiderman" is not a subclass of "Spider" or "Man" 
2. Multiple modules can be mixed-in to a class.

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:50:38Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:46:59Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:39:49Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:38:56Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:36:04Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:31:20Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:27:48Z

Jechen:

CSC/ECE 517 Fall 2010/ch2 2f EC

2010-09-21T19:25:33Z

Jechen: