Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-24T02:15:40Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as [http://en.wikipedia.org/wiki/Uncle_Bob "Uncle Bob"], discuses several principals of object oriented design. According to Martin, his principals "expose the dependency management aspects of [http://en.wikipedia.org/wiki/Object-oriented_programming OOD] as opposed to the conceptualization and modeling aspects" [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively
resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most [http://en.wikipedia.org/wiki/Programming_language languages], a [http://en.wikipedia.org/wiki/Class_%28computer_science%29 class] is used to represent a single unit of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are units of functionality that are designed to be portable.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an "off the shelf" product in new applications. This "off the shelf" approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

===REP with Respect to Modern Version Control Systems===
With modern [http://en.wikipedia.org/wiki/Version_control_system version control systems], it is relatively simply to [http://en.wikipedia.org/wiki/Baseline_%28configuration_management%29 baseline] revision of code. Tools such as [http://en.wikipedia.org/wiki/Subversion_%28software%29 Subversion] and [http://en.wikipedia.org/wiki/Concurrent_Versions_System CVS] allow working, released, code to be copied and used in other projects.

===REP with Respect to Agile Methodologies===
[http://en.wikipedia.org/wiki/Agile_software Agile software] development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system using the established process and used in the new application. The REP would, in this case, appears to be well within one of the [http://agilemanifesto.org/principles.html Twelve Principals of Agile Software], “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, "Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006

[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-24T02:09:18Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as [http://en.wikipedia.org/wiki/Uncle_Bob ["Uncle Bob"]], discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively
resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single unit of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are units of functionality that are designed to be portable.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an "off the shelf" product in new applications. This "off the shelf" approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

===REP with Respect to Modern Version Control Systems===
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

===REP with Respect to Agile Methodologies===
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, "Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006

[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-24T02:07:02Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as “Uncle Bob”, discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively
resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single unit of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are units of functionality that are designed to be portable.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an "off the shelf" product in new applications. This "off the shelf" approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

===REP with Respect to Modern Version Control Systems===
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

===REP with Respect to Agile Methodologies===
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, "Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006

[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-19T00:25:45Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as “Uncle Bob”, discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single units of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are the functionality object orient designed that are made to be portable units of functionality.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an “off the shelf” product in new applications. This “off the shelf” approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

REP with Respect to Modern Version Control Systems
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

REP with Respect to Agile Methodologies
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system being used using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006

[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-19T00:25:19Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as “Uncle Bob”, discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single units of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are the functionality object orient designed that are made to be portable units of functionality.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an “off the shelf” product in new applications. This “off the shelf” approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

REP with Respect to Modern Version Control Systems
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

REP with Respect to Agile Methodologies
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system being used using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3] Ducasse, Stéphane (University of Berne); Nierstrasz, Oscar; Schärli, Nathanael; Wuyts, Roel; Black, Andrew P. Source: ACM Transactions on Programming Languages and Systems, v 28, n 2, p 331-388, 2006
Database: Compendex

[4] Beck, et. al, Principles behind the Agile Manifesto, Available at: http://agilemanifesto.org/principles.html

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-18T23:49:46Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as “Uncle Bob”, discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single units of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are the functionality object orient designed that are made to be portable units of functionality.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an “off the shelf” product in new applications. This “off the shelf” approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

REP with Respect to Modern Version Control Systems
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

REP with Respect to Agile Methodologies
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system being used using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===
[1] Object Oriented Design Principals, Available at: http://www.surfscranton.com/Architecture/ObjectOrientedDesignPrinciples.htm

[2] Martin, Robert C., Granularity, Available at: http://www.objectmentor.com/resources/articles/granularity.pdf

[3]

CSC/ECE 517 Fall 2009/wiki3 16 eit

2009-11-18T23:42:01Z

Manhattan:

==Reuse Release Equivalency Principal==

===Introduction===
In several books and other writings, Bob Martin, also know in the Computer Science world as “Uncle Bob”, discuses several principals of object oriented design. According to Martin, his principals “expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects” [1]. That is, his principals help software engineers understand that there are dependencies that must be managed when using object oriented design.

One of Martin’s principals is commonly referred to as the Reuse Release Equivalency Principal (REP). Martin’s REP states:

"The granule of reuse is the granule of release. Only components that are release though a tracking system can be effectively resulted. This granule is the package." [2]

===Detailed Discussion of REP===
It is well know that one of the primary advantages of object oriented design is the ability to reuse code from one application in other applications that require the same functionality. In most languages, a class is used to represent a single units of functionality. Stephane Ducasse, et. al, further define classes to have two roles in object orient design. Ducasse, et. al. states that classes are primarily generators of instances, but are also units of reuse [3]. That is, classes are the functionality object orient designed that are made to be portable units of functionality.

If it is accepted that the unit of reuse is the class then, according to Martin’s REP, the class must first be released though a formal control process before it can be reused. But why must it be released? Why can’t a software engineer simply copy and paste code from one program to another, or copy and paste snippets? While this may work in some cases, Martin suggests that this is not good practice. Martin discusses several reasons why. For example, if code is simply copied from one application to another, and a bug is found in the original code, the maintainer of the application the code was copied to must have a way to find this out. That maintainer must also make the same changes. However, if a class is tested, peer reviewed, documented, and maintained though a formal revision control process, it can be used as an “off the shelf” product in new applications. This “off the shelf” approach has several advantages according to Martin. The class can be treated as a “black box”; that is, the user does not need understand the inner workings of the class. The user may simply update the library module if fixes to the original code are made [2].

REP with Respect to Modern Version Control Systems
With modern version control systems, it is relatively simply to baseline revision of code. Tools such as Subversion and CVS allow working, released, code to be copied and used in other projects.

REP with Respect to Agile Methodologies
Agile software development methodologies are those that stress flexibility in the software’s requirements as the project progresses. These methods contrast methods such as the Waterfall Method witch stress design to a clear and well defined set of requirements.

There are potential issues with REP when looked at against Agile Methodologies. For example if, during the course of an agile project, functionality is needed from a previously designed and released class, it can be used in the new application without violating REP. That is, the class and simply be checked out of the version control system being used using the established process and used in the new application. The REP would, in this case, appears to be well within one of the Twelve Principals of Agile Software, “Continuous attention to technical excellence and good design enhances agility” [4].

However, Agile Methodologies all have the general philosophy of “get it working” in small chucks. One of the Twelve Principals of Agile Software states, Working software is the primary measure of progress” [4]. In this case, it is reasonable to think that one developer may write some code that is of use to another on the team. If this is the case, the developers may be able to just be able to copy and paste the code and get a working piece of software. In this case, REP violates one of the Agile Software movement’s Twelve Principals.

===References===

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T02:10:05Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming language that perform different actions based on the current state of a variable or object. Examples of conditional statements include the “if” statement and the “switch” statement. This concept of [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted [http://en.wikipedia.org/wiki/Code_refactoring refactoring] technique. This article explores several examples of why replacing conditional statements with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, before beginning our discussion of why conditional statements are bad, let's look at a simple example of when they are useful and appropriate.

Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a class's method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. For example, in Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be added to a class to enforce that subclasses implement certain methods.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:50:00Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming language that perform different actions based on the current state of a variable or object. Examples of conditional statements include the “if” statement and the “switch” statement. This concept of [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted [http://en.wikipedia.org/wiki/Code_refactoring refactoring] technique. This article explores several examples of why replacing conditional statements with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, before beginning our discussion of why conditional statements are bad, let's look at a simple example of when they are useful and appropriate.

Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a class's method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:46:28Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming language that perform different actions based on the current state of a variable or object. Examples of conditional statements include the “if” statement and the “switch” statement. This concept of [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted [http://en.wikipedia.org/wiki/Code_refactoring refactoring] technique. This article explores several examples of why replacing conditional statements with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:45:56Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming language that perform different actions based on the current state of a variable or object. Examples of conditional statements include the “if” statement and the “switch” statement. This concept of [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted [http://en.wikipedia.org/wiki/Code_refactoring refactoring] technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:43:29Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming language that perform different actions based on the current state of a variable or object. Examples of conditional statements include the “if” statement and the “switch” statement. [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:41:44Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements] are statements in a programming languages that perform different actions given the current state of a variable. Examples of conditional statements include “if” statements or “switch” statements. [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:41:28Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One way polymorphism can help make code more elegant and maintainable is by reducing the number of conditional statements. [http://en.wikipedia.org/wiki/Conditional_%28programming%29 Conditional statements are statements in a programming languages that perform different actions given the current state of a variable. Examples of conditional statements include “if” statements or “switch” statements. [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:37:15Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of [http://en.wikipedia.org/wiki/Object-oriented_programming object oriented] systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such way is by reducing conditional statements, such as “if” statements or “switch” statements. [http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html “Replacing Conditional with Polymorphism”] is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-15T01:31:32Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as a “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let's implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-11T20:59:10Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as an “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on "abstract" classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:20:02Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as an “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on ‘abstract’ classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information on Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:19:34Z

Manhattan:

Student: Manhattan

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as an “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on ‘abstract’ classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information in Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:18:30Z

Manhattan:

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

==Conditional Statements Security Risk==
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as an “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on ‘abstract’ classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information in Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:17:54Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:17:20Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:17:03Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:16:50Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:15:58Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki2 4 railroad

2009-10-09T01:15:25Z

Manhattan: Revision 1

==Introduction==

[http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming Polymorphism] is one of the fundamental strengths of object oriented systems and design. Polymorphism can not only make code more closely mirror the “real” world, it can also help make code more elegant and maintainable. One such was is by reducing conditional statements, such as “if” statements or “switch” statements. “Replacing Conditional with Polymorphism” is a commonly accepted refactoring technique. This article explores several examples of why replacing conditionals with polymorphism is desirable.

==When Conditional Statements Are Useful==
In large software systems, conditional statements can make code less modular and require that more lines of code be updated when a change needs to be made. However, when are they useful?

Let’s start by considering a simple example. Let’s say we have a system that allows for management of train stations. Perhaps, a snippet of code from the system for selecting a station might look like:

if(users_selection == “PHL”)
{
/* Station = Philadelphia, PA */
}
else if(users_selection == “NYC”)
{
/* Station = New York, NY */
}
else if(user_selection == “PVD”)
{
/* Station = Providence, RI */
}
else if(user_selection == “RDU”)
{
/* Station = Raleigh, NC */
}

... and so on ...

This code works well. Even when a new station needs to be added, the programmer can simply add another “else if” statement to make the code work. Simple conditional statements, such as the example above, are arguably necessary in every non-trivial program. When encapsulated within a classes method to perform simple comparisons, conditionals provide a very simple and elegant way to add functionality to the system.

==Conditionals that Make it Hard to Maintain Code==
Arguably, any non-trivial software system will contain some form of complex logic. Let’s say our system also contains a way to get the services the station offers; these services might be: food for travelers, train fuel, connections to local subway trains, etc. If we tried to use conditional statements to do this, we might see something like:

switch( my_station.get_name() )
{
case PHL:
/* Return things about Philadelphia’s train station */
break;

case NYC:
/* Return things about New York’s train station */
break;

case RDU:
/* Return things about Raleigh’s station */
break;

case PVD:
/* Return things about Providence’s station */
break;

... and so on ...

}

This approach will work, but, what if each station has many different types of services? Or, what if certain services are not available at certain stations. That is, what if each station has services, but they are mostly unique to that station. We could probably get around this by creating, and returning, an instance of an STATION_INFO class. However, this code is arguably not very elegant. In one switch statement, there could be many different things happening and it could be very difficult to maintain.

But what if we created a train station base class, then created subclasses that represent each individual train station? We could use polymorphism to always return the correct station information. For example,

TRAIN_STATION[ ] the_stations = new TRAIN_STATION[10];

the_stations[0] = new PHL_STATION;
the_stations[1] = new NYC_STATION;
the_stations[2] = new RDU_STATION;
the_stations[3] = new PVD_STATION;

... and so on ...

Assuming each subclass is required by the TRAIN_STATION superclass to implement a method called ‘get_my_services’, the switch statement in the previously example would simply become:

/* Get Philly’s train station services */
services = the_airports[0]. get_my_services;

/* Get New York’s train station services */
services = the_airports[1]. get_my_services;

/* Get Raleigh's train station services */
services = the_airports[2]. get_my_services;

/* Get Providence’s train station services */
services = the_airports[3]. get_my_services;

... and so on ...

Now, if any of the services need to be modified, updated, or otherwise changed, we can simply go to the specific train station subclass and modify its ‘ get_my_services’ method. The code is very easy to understand.

Conditional Statements Security Risk
Conditional statements can also pose a significant security risk that can be mitigated using polymorphism. Keeping with our train station management system example, let’s assume we have functionally to return a string that indicates the name of the local public transit system that connects to the train station. Again, if we used a conditional, such as an “switch” statement we may have:

switch( my_station.get_transit_service_string() )
{
case PHL:
public_transit_name = “SEPTA”;
break;

case NYC:
public_transit_name = “MTA”;
break;

...and so on ...

Notice that Raleigh and Providence were both left off. Why? Perhaps these cities have public transit systems, but they do not connect to the train station. Perhaps the programmer forgot to put them in. There is an infinite number of reasons why they may have been left off. With a standard conditional statement, there is virtually no way to enforce that all conditions are enumerated. If something such as an uninitiated string or other variable is introduced, it could cause problems in other parts of the system. Of course, in all major languages, a ‘switch’ statement has a ‘default’ case that can be used as a catch-all.

When using polymorphism, this problem can be easily avoided. Java, C++, and Ruby all contain ways to enforce that subclasses implement certain methods or at least allow the base class to “safely” implement the method. In Java, a class’s methods can be declared as ‘abstract’, in C++ they can be declared as virtual, and in Ruby, the ‘method_missing’ method can be used.

For example, let implement the connecting mass transit string with an abstract method in Java.

/* The Base Class */
class TRAIN_STATION
{
abstract string get_transit_service_string(void);

... other methods ...
}

By declaring the ‘get_transit_service_string’ method as ‘abstract’, we force any classes that inherit from TRAIN_STATION to implement the ‘get_transit_service_string’ method. If not, a compiler error will be generated.

==External Resources==
The following are a list of external resources that contain more information and examples on polymorphism vs. conditional statements.

[1] An example of an Employee class that calculates salary:
http://www.eli.sdsu.edu/courses/spring01/cs635/notes/refactorPatterns/refactorPatterns.html#Heading3

[2] Several Examples of refactoring code to replace conditionals with polymorphism:
http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism

[3] Information on ‘abstract’ classes and methods in Java:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

[4] Information on Ruby’s ‘method_missing’ method:
http://www.rubycentral.com/pickaxe/ref_c_object.html

[5] Information in Virtual methods in several languages:
http://en.wikipedia.org/wiki/Virtual_function

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-05T13:59:59Z

Manhattan:

Ruby and Java from a Security Perspective 
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

In Java, Security can be considered in three contexts :
1) Virtual Machine Security
2) Application Security
3) Network Security

== Ruby ==

'''''“Safe Levels” in Ruby''''' 
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security''''' 
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end 
def another_good_method
... # some more good code
end
end 
Class Bad_code
def good_method
... #some BAD code, that looks good
end 
def another_good_method
... #some more bad code
end
end 
def my_method(good_code)
good_code.good_method
good_code.another_good_method
end 
my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

'''''Automatic Bounds Checking''''' 
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

'''''Cryptographic Libraries''''' 
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

'''''Survey of Current and Past Publish Security Vulnerabilities''''' 
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

== Java Security Features ==

'''''Programs are not allowed to access arbitrary memory locations''''' 
For example, casting between an
int and an Object is strictly illegal in Java. 

'''''Variables may not be used before they are initialized''''' 
If a program were able to read the value of an uninitialized variable, the effect would be the same as if
it were able to read random memory locations. A Java class wishing to exploit this defect might then
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the
user's machine. To prevent this type of attack, all local variables in Java must be initialized before
they are used, and all instance variables in Java are automatically initialized to a default value.

'''''Objects cannot be arbitrarily cast into other objects''''' 
Consider the below example.

public class CreditCard { 
private String acctNo; 
}
public class CreditCardSnoop { 
public String acctNo; 
} 

Then the following code will not be allowed execute:

CreditCard cc = Wallet.getCreditCard( ); 
CreditCardSnoop snoop = (CreditCardSnoop) cc; 
System.out.println("Ha! Your account number is " + snoop.acctNo); 

Java does not allow arbitrary casting between objects; an object can only be cast to one of its
superclasses or its subclasses. 

To satisfy the compiler code can be changed as follows: 
Object cc = Wallet.getCreditCard( ); 
CreditCardSnoop snoop = (CreditCardSnoop) cc; 

In this case, the virtual machine will throw a ClassCastException when the
snoop variable is assigned to thwart the attack.

'''''The Bytecode Verifier''''' 
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute.

For example, consider the following classes

public class CreditCard { 
public String acctNo = "0001 0002 0003 0004"; 
} 

public class Test { 
public static void main(String args[]) { 
CreditCard cc = new CreditCard( ); 
System.out.println("Your account number is " + cc.acctNo); 
} 
} 

If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of
acctNo to be private and recompile only the CreditCard class. We then have two class files and the
Test class file contains Java code that illegally accesses the private instance variable acctNo of the
CreditCard class and hence will not be allowed to execute.

== References ==
[1] Hunt, Andrew and Thomas David. "Programming Ruby, The Pragmatic Programmer's Guide". 
[2] "Crypt" Library Website: http://crypt[dot]rubyforge[dot]org/ 
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-05T13:58:41Z

Manhattan:

Ruby and Java from a Security Perspective 
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

In Java, Security can be considered in three contexts :
1) Virtual Machine Security
2) Application Security
3) Network Security

== Ruby ==

'''''“Safe Levels” in Ruby''''' 
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

'''''Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security''''' 
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end 
def another_good_method
... # some more good code
end
end 
Class Bad_code
def good_method
... #some BAD code, that looks good
end 
def another_good_method
... #some more bad code
end
end 
def my_method(good_code)
good_code.good_method
good_code.another_good_method
end 
my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

'''''Automatic Bounds Checking''''' 
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

'''''Cryptographic Libraries''''' 
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

'''''Survey of Current and Past Publish Security Vulnerabilities''''' 
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

== Java Security Features ==

'''''Programs are not allowed to access arbitrary memory locations''''' 
For example, casting between an
int and an Object is strictly illegal in Java. 

'''''Variables may not be used before they are initialized''''' 
If a program were able to read the value of an uninitialized variable, the effect would be the same as if
it were able to read random memory locations. A Java class wishing to exploit this defect might then
declare a huge uninitialized section of variables in an attempt to snoop the memory contents of the
user's machine. To prevent this type of attack, all local variables in Java must be initialized before
they are used, and all instance variables in Java are automatically initialized to a default value.

'''''Objects cannot be arbitrarily cast into other objects''''' 
Consider the below example.

public class CreditCard { 
private String acctNo; 
} 

public class CreditCardSnoop { 
public String acctNo; 
} 

Then the following code will not be allowed execute:

CreditCard cc = Wallet.getCreditCard( ); 
CreditCardSnoop snoop = (CreditCardSnoop) cc; 
System.out.println("Ha! Your account number is " + snoop.acctNo); 

Java does not allow arbitrary casting between objects; an object can only be cast to one of its
superclasses or its subclasses. 

To satisfy the compiler code can be changed as follows: 
Object cc = Wallet.getCreditCard( ); 
CreditCardSnoop snoop = (CreditCardSnoop) cc; 

In this case, the virtual machine will throw a ClassCastException when the
snoop variable is assigned to thwart the attack.

'''''The Bytecode Verifier''''' 
This is used to check whether the code compiled by the compiler is a legal java code. The Java verifier examines all such application byte code and, using a fancy set of heuristics, identifies code that doesn't play by the rules. Once byte code is verified, the virtual machine knows that it's safe to execute.

For example, consider the following classes

public class CreditCard { 
public String acctNo = "0001 0002 0003 0004"; 
} 

public class Test { 
public static void main(String args[]) { 
CreditCard cc = new CreditCard( ); 
System.out.println("Your account number is " + cc.acctNo); 
} 
} 

If we run this code, we'll create a CreditCard object and print out its account number. If we change the definition of
acctNo to be private and recompile only the CreditCard class. We then have two class files and the
Test class file contains Java code that illegally accesses the private instance variable acctNo of the
CreditCard class and hence will not be allowed to execute.

== References ==
[1] Hunt, Andrew and Thomas David. "Programming Ruby, The Pragmatic Programmer's Guide". 
[2] "Crypt" Library Website: http://crypt[dot]rubyforge[dot]org/ 
[3] Ruby Website, Security Sections: http://www[dot]ruby-lang[dot]org/en/security/

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:41:24Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:35:31Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:34:17Z

Manhattan:

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:32:03Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end 
def another_good_method
... # some more good code
end
end 
Class Bad_code
def good_method
... #some BAD code, that looks good
end 
def another_good_method
... #some more bad code
end
end 
def my_method(good_code)
good_code.good_method
good_code.another_good_method
end 
my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:30:48Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:28:24Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:26:46Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:25:44Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted 
>> my_string = String.new # A new string is created 
=> "" 
>> my_string.tainted? # The string is not tainted; there has been no external influence 
=> false 
>> my_string = "Hello" # Still no external influence 
=> "Hello" 
>> my_string.tainted? 
=> false 
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted 
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:20:54Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:20:18Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

<math>
#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true
</math>

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:19:27Z

Manhattan:

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

“Safe Levels” in Ruby
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:18:18Z

Manhattan: Ruby and Java from a Security Perspective

Ruby and Java from a Security Perspective
Students: wolf 27 and Manhattan

----

== Introduction ==
It is widely held that the three “pillars” of a secure system are confidentiality, availability, and integrity. That is, is a users data safe from unauthorized viewing/disclosure; is the users data available when they want it; and is the data the same as what they expected. There are many techniques, algorithms, and methods available to ensure these three pillars. The language used to develop the software on a secure system can play a major role in how effective in how algorithms, etc. help protect the confidentiality, availability, and integrity of secure data. This article compares two popular languages, Ruby and Java with respect to some of features of each language that aid in developing a secure software system.

== Ruby ==

''“Safe Levels” in Ruby'''''Bold text'''
Arguable one of Ruby’s features with respect to security is its “Safe Levels”. Ruby implements five levels of data checking to help prevent what its calls “tainted” variables from being used in other parts of the code where the system could be exploited.

All objects in Ruby are marked as “tainted” if they are derived from some external source. For example, an object is tainted if it read using ‘gets’, read from a file, is an environment variable, etc. Each Ruby object contains a method named, ‘tainted?’ as well as methods named ‘taint’ and ‘untaint’.

The ‘tainted?’ method is used to return a boolean value to indicate if the variable is tainted or not. Likewise, the ‘taint’ method is used to taint an untainted object and ‘untaint’ is used to remove a tainted label from an object. The code below shows a simple example of a String object becoming tainted.

#Tainted vs. Untainted
>> my_string = String.new # A new string is created
=> ""
>> my_string.tainted? # The string is not tainted; there has been no external influence
=> false
>> my_string = "Hello" # Still no external influence
=> "Hello"
>> my_string.tainted?
=> false
>> my_string = my_string + gets #Since part of the string now came from the console, it is tainted
World!
=> "Hello World!\n"
>> my_string.tainted?
=> true

To help manage tainted and untainted objects, Ruby define a built in constant named $SAFE that allows the user to define what “safe level”. The $SAFE variable is simply set at the beginning of the program in the way any other variable would be. For example,
$SAFE = 3
sets Ruby’s “safe level” to 3.

Each safe level allows (or disallows) certain actions, primarily based on whether an object is tainted or untainted. There are a few other operations that are also disallowed by Ruby at the various safe levels. Note that Ruby’s default safe level is 0, which means there all operates are allowed regardless of the the tainted status of the object. The books “Programming Ruby” [1] provides an excellent table to use as reference for the actives allowed and disallows at each safe level. Below are some highlight of each safe level.

$SAFE = 0
Default “Safe Level”
No additional security features
All operations allowed on all untainted and tainted variables
$SAFE >= 1
Calling the ‘glob’ or ‘eval’ methods on tainted strings is disallowed.
Loading a file using a string that is tainted is disallowed.
Executing system commands using a tainted string is disallowed.
$SAFE >= 2
Loading a file from a source that is writable by ‘world’ is disallowed.
$SAFE >= 3
All object created are tainted and no object may not be untainted using the untaint method.
$SAFE >= 4
Essentially creates a Sandbox (an isolated, safe, place to run untrused code)
Writing to files is disallowed
Modifying global variable is disallowed.

Ruby’s Unbounded Polymorphism (a.k.a. Duck Typing) and Security
Ruby’s unbounded polymorphism functionally is arguably very powerful. However this power functionally could also create a potential problem with code developed. Since Ruby is a dynamically typed language, it is not possible to check and ensure that objects being used are of the expected type. If that object looks like another object, it can be treated as that object.

If not managed properly, an adversary or malicious piece of code could be executed unintentionally because of Ruby’s unbounded polymorphism. Consider the code below.

Class Good_code
def good_method
... # some good code
end

def another_good_method
... # some more good code
end
end

Class Bad_code
def good_method
.... #some BAD code, that looks good
end

def another_good_method
... #some more bad code
end
end

def my_method(good_code)
good_code.good_method
good_code.another_good_method
end

my_method(Bad_code.new)

In the example above, the malicious code will run, even though the developer of my_method thought and intended to only run code from the ‘good_code’ object. The developer must take greater caution when implementing code that takes another objects as to unintentionally execute a different object.

Automatic Bounds Checking
Ruby automatically checks bounds of data structures such as arrays. Bounds checking is very important to creating a secure system. If a user, intentionally or unintentionally, is able cause code to access an array index outside of the array, the system may crash, other data in memory may be overwritten, or unexpected (possibly private) data may be returned.

Cryptographic Libraries
The ability to perform basic cryptographic functions is necessary to help ensure the confidentially of data stored on a system (thought encryption) and the integrity of data (by cryptographic signature/hash). Ruby provides, built in, only a very limited set of cryptographic functionally. One such function is the String classes crypt method.

There are several open source library for performing cryptographic functions on objects available for Ruby such as crypt [2]. The crypt library provides access to such encryption algorithms AES, Blowfish, and IDEA.

Survey of Current and Past Publish Security Vulnerabilities
The official Ruby site [3] contains a security section that list a number of current and past security vulnerabilities found.

CSC/ECE 517 Fall 2009/wiki1a 10 wolf27-Manhattan

2009-09-04T14:08:13Z

Manhattan:

Wiki 1a Page