Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-25T05:24:41Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. According to [2], the instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as shown below:

[[Image:fig4.png]]

In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Conclusion ==

To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability" [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-25T05:24:35Z

Notfound:

Topic: Stable Dependencies Principlex

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. According to [2], the instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as shown below:

[[Image:fig4.png]]

In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Conclusion ==

To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability" [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-25T05:23:20Z

Notfound: /* Conclusion */

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-25T05:22:54Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. According to [2], the instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as shown below:

[[Image:fig4.png]]

In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Conclusion ==

To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability." [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-25T05:20:40Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. The instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as shown below:

[[Image:fig4.png]]

In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Conclusion ==

To summarize, the SDP is one of several package design principles. It helps design "systems with a high degree of reusability and testability." [1]. The principle states that "a package should always depend upon packages that are more stable than it is," and this article demonstrates methods to identify which packages are more stable than others.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-23T01:16:41Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. The instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as shown below:

[[Image:fig4.png]]

In general, lower values result in more stable packages. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to be effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-20T21:06:41Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. The instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as follows:

[[Image:fig4.png]]

The lower the value, the more stable the package is considered to be. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf

CSC/ECE 517 Fall 2009/wiki3 18 301

2009-11-20T21:06:33Z

Notfound:

Topic: Stable Dependencies Principle

== Introduction ==

Package Design is a challenging area of Object Oriented Programming (OOP), an important part of Software Engineering. An inefficiently designed system can be a root cause of many problems, thus, it is vital to have a solid understanding of various design approaches. This article discusses Stable Dependencies Principle, one of a few key package design principles that software engineers should be aware of.

== Definition of Package==

In OOP, a package is one or more classes logically grouped into a single unit. According to [4], "classes often have dependencies on other classes, creating package dependencies relationships." The below principle can interchangeably be applied to small packages of just one class, and to larger ones consisting of multiple classes.

== Definition of Instability ==

First, let's discuss why certain packages are considered stable, and others are not. The instability of any package can be calculated using the following formula:

I (instability) = Ce / ( Ca + Ce )

In this formula:

Ce – the number of other modules that our package requires in order to operate correctly. In other words, this is an indicator of package ''independence''.

Ca – the number of packages that can be viewed as “dependents“, i.e., “depend upon classes within the package”. This is an indicator of package ''responsibility''.

Therefore, in order for a package to be completely independent and also stable, it should not be dependent upon other packages.

For example, let’s look at the following component diagram:

[[Image:fig1.png]]

The ''Wheel'' class in this example is shown to be not dependent on any other module.

Using the above formula:

I(W) = 0 / ( 3 + 0 ) = 0

I(W) has the instability of zero. In other words, even though the ''Wheel'' class is “responsible” for three classes (Ca=3), it is not dependent upon any of them (Ce = 0), thus resulting in a stable package.

Respectively, ''instable'' or ''irresponsible'' packages would have the instability of 1, as shown below:

[[Image:fig2.png]]

In this case, the ''Car'' class does not have any dependent classes (Ca = 0), yet itself depends upon three classes – ''Wheel'', ''Engine'', and ''Suspension'' (Ce = 3).

Let’s calculate the instability of the ''Car'' package:

I(C) = 3 / ( 0 + 3 ) = 3 / 3 = 1

The instability of 1 indicates a high level of volatility of the ''Car'' module.

== Stable Dependencies Principle ==

The ''Stable Dependencies Principle'' (SDP) states that “a package should always depend upon packages that are more stable than it is.” Ideally, the direction of dependencies should go from high volatile to more stable packages.

So how do we know whether a certain component design follows the SDP? Let's look at another example. The following is a more complex diagram outlining several ''Car'' components and their sub-components:

[[Image:fig3.png]]

The instability of each of the modules would be calculated as follows:

I(C) = 3 / (0 + 3) = 1 (the least stable)
I(W) = 2 / (1 + 2) = 0.66
I(E) = 2 / (1 + 2) = 0.66
I(Su) = 1 / (1 + 1) = 0.5
I(T) = 0 / (1 + 0) = 0 (the most stable)
I(R) = 0 / (1 + 0) = 0
I(Cyl) = 0 / (1 + 0) = 0
I(O) = 0 / (1 + 0) = 0
I(St) = 0 / (1 + 0) = 0

After replacing each class with its corresponding instability value, the diagram would look as follows:

[[Image:fig4.png]]

The lower the value, the more stable the package is considered to be. In our case, all dependencies progress in the direction of stability, thus, according to the SDP, our design is proven to effective.

Another important consideration when it comes to stability is that more stable packages should not be changed often. On the other hand, a highly volatile class can be changed easily, without affecting other packages in the system.

== Links ==

[1] The Tipping Point: Stability and Instability in OO Design, http://www.ddj.com/architect/184415285

[2] On Package Design, https://prof.hti.bfh.ch/fileadmin/home/due1/uml_dp/udp_package_design_200906.pdf

[3] What Makes A Good Object-Oriented Design?, http://ootips.org/ood-principles.html

[4] Principles of Package Design, http://nandokakimoto.wordpress.com/2009/05/15/principles-of-package-design/

[5] Stability, http://www.objectmentor.com/resources/articles/stability.pdf
c

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T04:04:31Z

Notfound: /* Conclusion */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes]. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes] (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an [http://en.wikipedia.org/wiki/Object_%28computer_science%29 object] figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving [http://en.wikipedia.org/wiki/Software_maintenance maintainability] and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T04:03:15Z

Notfound: /* Pros */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes]. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes] (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an [http://en.wikipedia.org/wiki/Object_%28computer_science%29 object] figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T04:00:47Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes]. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes] (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:59:39Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all [http://en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29 child classes]. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:58:00Z

Notfound: /* Pros */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:57:31Z

Notfound: /* Cons */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the [http://en.wikipedia.org/wiki/Development_life_cycle development life cycle]. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:56:19Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:50:48Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar (newly defined), case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:48:01Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "What kind of vehicle do you have?"
#Expects Car, Truck, SportsCar, or Bicycle, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:46:44Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

What kind of vehicle do you have?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "What kind of vehicle do you have?"
type = gets # expects Car, Truck, or SportsCar, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:44:41Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most important part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:42:36Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car"
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most import part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:42:02Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

For example, the new class could be defined as follows:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

And the most import part is that the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:39:44Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

That is:

<pre>
class SportsCar < Vehicle # this is a new class
def initialize
super
puts "I am a sports car
end

def get_type_of_fuel
"I like 93 octane gasoline"
end
end
</pre>

However, the <code>Driver</code> class would remain absolutely unchanged, yet fully support the new addition:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:36:06Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code of the <code>Driver</code> class would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:35:04Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>SportsCar</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
elsif my_car.class == Bicycle # new class
puts "I don't need any fuel" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:18:14Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
end
end
</pre>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:17:39Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code would look as follows:

<pre>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
end
end
</pre

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:17:06Z

Notfound: /* Example with <code>If</code> statements */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement.

The updated code would look as follows:

<code>
class Driver
puts "Do you have a Car or a Truck?"
#Expects Car or Truck, case sensitive
type = gets
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
elsif my_car.class == SportsCar # new class
puts "I like 93 octane gasoline" # new output
end
end
</code>

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:06:33Z

Notfound: /* Pros */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should be designed so that they are fully responsible for manipulating object's data which should normally be declared as <code>private</code>.

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:04:54Z

Notfound: /* Cons */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should take full responsibility for manipulating object's data

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle. That requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T03:04:09Z

Notfound: /* Cons */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should take full responsibility for manipulating object's data

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement.

Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

Finally, implementing polymorphism in classes takes a lot of preparation and requires more time to be spent up front. Ultimately, the majority of the design decisions are made very early in the development life cycle, and requires a great deal of understanding of the issue that is being solved.

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T02:56:37Z

Notfound: /* Links */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should take full responsibility for manipulating object's data

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] Polymorphism and Interfaces, http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T02:56:11Z

Notfound: /* Links */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should take full responsibility for manipulating object's data

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

[5] http://www.artima.com/objectsandjava/webuscript/PolymorphismInterfaces1.html

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-15T02:55:50Z

Notfound: /* Pros */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

Another advantage is that we let "an object figure out how it should behave" [5]. With that in mind, methods should take full responsibility for manipulating object's data

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:27:13Z

Notfound: /* Introduction */

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, will talk about pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:17:16Z

Notfound:

Topic: If-statements considered harmful, and can be replaced by uses of polymorphism.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:15:58Z

Notfound:

Topic: If-statement Considered Harmful.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:15:39Z

Notfound:

<center>Topic: If-statement Considered Harmful.</center>

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:14:59Z

Notfound:

Topic: If-statement Considered Harmful.

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:13:35Z

Notfound: /* Example with <code>If</code> statements */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new <code>Vehicle</code> types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:12:55Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

It is important to point out that the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:11:30Z

Notfound: /* Example of <code>If</code> replaced by polymorphism */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's [http://en.wikipedia.org/wiki/Refactor refactor] our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:09:16Z

Notfound: /* Introduction */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some code examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:08:59Z

Notfound: /* Introduction */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism, and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:08:40Z

Notfound: /* Introduction */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism].

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism , and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:07:49Z

Notfound: /* Introduction */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of polymorphism , and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:06:34Z

Notfound: /* Introduction */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in [http://en.wikipedia.org/wiki/FORTRAN FORTRAN] in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of both, and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:05:50Z

Notfound: /* Links */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in FORTRAN in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of both, and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
One of the cons of polymorphism is that the "behaviors" are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

[4] Polymorphism in object-oriented programming, http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:03:44Z

Notfound: /* Cons */

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:02:32Z

Notfound: /* Cons */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in FORTRAN in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of both, and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
Among the cons is that the behaviors are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is also "potentially harder to
understand" [3].

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf

CSC/ECE 517 Fall 2009/wiki2 4 va

2009-10-10T03:01:58Z

Notfound: /* Pros and Cons of Polymorphism */

__TOC__

== Introduction ==

The <code>If</code> statement, a conditional language structure, has been available to programmers for quite some time. It was first introduced in FORTRAN in a form of an [http://en.wikipedia.org/wiki/Arithmetic_IF arithmetic <code>If</code> statement] back in 1957 [1]. The logic behind this language element is simple. The control of the program is redirected to one of three labels, depending on the value of the analyzed arithmetic expression (which could be negative, positive, or zero). Over the years, this language feature had become obsolete and was replaced by a [http://en.wikipedia.org/wiki/Conditional_%28programming%29 logical <code>If</code> statement] (if-then-else), the one that is still widely used to this day.

The logical <code>If</code> statement is very familiar to most programmers as it is one of the first language concepts they learn. Despite that, it is a cause of many code errors. Since the <code>If</code> statement is more suitable for [http://en.wikipedia.org/wiki/Structured_programming structured programming], most today's [http://en.wikipedia.org/wiki/Object-oriented object-oriented] languages have more sophisticated mechanisms to replace it. One of such approaches is a use of polymorphism.

This paper will discuss ways in which a polymorphism technique can be applied to replace the <code>If</code> control structures, pros and cons of both, and will demonstrate some examples written in [http://en.wikipedia.org/wiki/Ruby_language Ruby language].

== What is wrong with using <code>If</code> statements? ==

Most of the time, a correctly written <code>If</code> statement would not cause any harm to one's code. It, however, possesses a potential to be error prone, as demonstrated by the following Ruby code:

i = 1 # or any other number

if i >= 0
puts "greater or equal to zero"
elsif i < 0
puts "less than zero"
else
puts "will never run!!!!"
end

As you can see from this example, the condition for the else part of the statement will never be met. This example does not suggest that a use of <code>If</code> statements should be avoided. It simply demonstrates a potential in conditional statements to be error prone.

== Example with <code>If</code> statements ==

Let's consider a simple code that would illustrate a use of <code>If</code> statement in an object-oriented language. First, we define a parent class, <code>Vehicle</code>, and two child classes - <code>Car</code> and <code>Truck</code>. We would then ask a user to choose which of the two classes they would like to initialize. The <code>If</code> statement performs a dynamic type checking, and then depending on the user's selection, suggests a type of fuel that would work with the chosen vehicle.

Below is a Ruby code that implements the above utilizing the <code>If</code> statement:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a commercial truck"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new

if my_car.class == Car
puts "I like 87 octane gasoline"
elsif my_car.class == Truck
puts "I like diesel"
end
end
</pre>

If we respond with <code>Car</code>, the output would look as follows:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

One apparent downside of this solution is that the code is not easily maintainable if the selection of vehicles
grows further. For instance, let's imagine we decided to add two new vehicle types, <code>Motorcycle</code> and <code>Bicycle</code>. In order to support this addition, we would need to add two new classes, as well as to modify the <code>If</code> statement (or, better to replace it with a more appropriate conditional, such as <code>Case</code>.)

== Example of <code>If</code> replaced by polymorphism ==

Now, let's refactor our code by implementing the same example using polymorphism. The first modification is to introduce a method named <code>get_type_of_fuel</code> in all child classes. Similar to the earlier example, the caller of the method has no way of knowing which class will be chosen as it would be a run-time decision.

Again, we will use Ruby code to demonstrate the new approach:

<pre>
class Vehicle
def initialize
puts "I am a vehicle"
end
end

class Car < Vehicle
def initialize
super
puts "I am a passenger car"
end

def get_type_of_fuel
"I like 87 octane gasoline"
end
end

class Truck < Vehicle
def initialize
super
puts "I am a truck"
end

def get_type_of_fuel
"I like diesel"
end
end

class Driver
puts "Do you have a Car or a Truck?"
type = gets # expects Car or Truck, case sensitive
my_car = eval(type).new
puts my_car.get_type_of_fuel
end
</pre>

If <code>Car</code> is selected, the output would remain the same:

Do you have a Car or a Truck?
Car
I am a vehicle
I am a passenger car
I like 87 octane gasoline

However, the maintainability of the application has improved. For instance, as we add new <code>Vehicle</code> types, the class <code>Driver</code> would remain completely intact. Thus, the only change would be to add new child classes (and they must contain a <code>get_type_of_fuel</code> method).

== Pros and Cons of Polymorphism ==

=== Pros ===
According to [3], one of the biggest advantages of polymorphism is that new class "features" can be added incrementally. Additionally, these separate class "behaviors" are coded independently from each other, "thus minimizing the possible interference."

=== Cons ===
Among the cons is that the behaviors are spread among multiple classes (abstractions), as opposed to having everything in one conditional statement. Another downside is that adding new methods/classes increases the complexity and the size of the code. It is also "potentially harder to
understand."

== Conclusion ==

As shown in this article, the use of <code>If</code> statements can be a cause of uncertainty. In many cases, <code>If</code> and other conditionals can be successfully transformed to polymorphism, also improving maintainability and flexibility of the application [3].

== Links ==
[1] Arithmetic IF, http://en.wikipedia.org/wiki/Arithmetic_IF

[2] Conditional statements, http://en.wikipedia.org/wiki/If_statement

[3] Transform Conditionals to Polymorphism, http://scg.unibe.ch/archive/papers/Duca00cTransform.pdf