Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T02:17:56Z

Srmunill: /* Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

===Advantages of Continuous Integration===

Because it encourages smaller changes to the code base that must be thoroughly tested by the test suite before the can be integrated, continuous integration greatly reduces issues with merging code into the code base.

Additionally, frequent updates by engineers helps to ensure that everyone is working with the latest version of the code base when they begin modifying code. This makes it much less likely that engineers will duplicate functionality or otherwise needlessly rewrite code.

Together, these advantages mean that less time will be wasted fixing conflicts in the code and therefore more time can be spent writing new code and working to complete the project.

===Disadvantages of Continuous Integration===

The disadvantage of Continuous Integration comes from one of it's requirements, extensive unit testing. If the test suites require a long period of time to verify that the system is still functioning, a lot of time can be used up waiting for these tests to complete. This is compounded because continuous integration encourages small changes to the code base. But, the entire test suite must be run each time a change is to be committed. At it's extreme, this could result in engineers spending more time running tests than on developing code.

Because of this, like Collective Ownership, Continuous Integration does not scale well to very large projects.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

[5] http://c2.com/cgi/wiki?ThoughtfulReactionsToXp

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T02:15:37Z

Srmunill: /* References */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

===Advantages of Continuous Integration===

Because it encourages smaller changes to the code base that must be thoroughly tested by the test suite before the can be integrated, continuous integration greatly reduces issues with merging code into the code base.

Additionally, frequent updates by engineers helps to ensure that everyone is working with the latest version of the code base when they begin modifying code. This makes it much less likely that engineers will duplicate functionality or otherwise needlessly rewrite code.

Together, these advantages mean that less time will be wasted fixing conflicts in the code and therefore more time can be spent writing new code and working to complete the project.

===Disadvantages of Continuous Integration===

The disadvantage of Continuous Integration comes from one of it's requirements, extensive unit testing. If the test suites require a long period of time to verify that the system is still functioning, a lot of time can be used up waiting for these tests to complete. This is compounded because continuous integration encourages small changes to the code base. But, the entire test suite must be run each time a change is to be committed. At it's extreme, this could result in engineers spending more time running tests than on developing code.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

[5] http://c2.com/cgi/wiki?ThoughtfulReactionsToXp

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T02:15:15Z

Srmunill: /* Disadvantages of Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

===Advantages of Continuous Integration===

Because it encourages smaller changes to the code base that must be thoroughly tested by the test suite before the can be integrated, continuous integration greatly reduces issues with merging code into the code base.

Additionally, frequent updates by engineers helps to ensure that everyone is working with the latest version of the code base when they begin modifying code. This makes it much less likely that engineers will duplicate functionality or otherwise needlessly rewrite code.

Together, these advantages mean that less time will be wasted fixing conflicts in the code and therefore more time can be spent writing new code and working to complete the project.

===Disadvantages of Continuous Integration===

The disadvantage of Continuous Integration comes from one of it's requirements, extensive unit testing. If the test suites require a long period of time to verify that the system is still functioning, a lot of time can be used up waiting for these tests to complete. This is compounded because continuous integration encourages small changes to the code base. But, the entire test suite must be run each time a change is to be committed. At it's extreme, this could result in engineers spending more time running tests than on developing code.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T02:10:42Z

Srmunill: /* Advantages of Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

===Advantages of Continuous Integration===

Because it encourages smaller changes to the code base that must be thoroughly tested by the test suite before the can be integrated, continuous integration greatly reduces issues with merging code into the code base.

Additionally, frequent updates by engineers helps to ensure that everyone is working with the latest version of the code base when they begin modifying code. This makes it much less likely that engineers will duplicate functionality or otherwise needlessly rewrite code.

Together, these advantages mean that less time will be wasted fixing conflicts in the code and therefore more time can be spent writing new code and working to complete the project.

===Disadvantages of Continuous Integration===

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T02:04:44Z

Srmunill: /* Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration is a philosophy on how code bases should be altered and generally work in conjunction with Collective Ownership. The basic mindset behind continuous integration is the engineers should hold on to code for as short a time period as possible before committing it back to the code base. This encourages small, incremental changes over big changes to the code base.

Under this philosophy, each engineer should integrate code they are working on at least daily, preferably every few hours. This will result in several integrations per day across the whole team. More so even than Collective Ownership, continuous integration requires an extensive unit test suite to function properly within a team.

===Advantages of Continuous Integration===

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

===Disadvantages of Continuous Integration===

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:57:08Z

Srmunill: /* Collective Ownership */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

===Negative Reactions to Collective Ownership===

Not everyone in the programming community believes that Collective Ownership is the best solution for managing a code base. Concerns about collective ownership include the thrashing of the code as engineers fight over which solution is best. Additionally, there is some concern that engineers will take less pride in work they do not see as "theirs" and therefore be less motivated.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

===Advantages of Continuous Integration===

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

===Disadvantages of Continuous Integration===

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:51:05Z

Srmunill: /* Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

===Advantages of Continuous Integration===

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

===Disadvantages of Continuous Integration===

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:49:50Z

Srmunill: /* Unit Tests and Collective Ownership */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|right|500px]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are five requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

===Advantages of Collective Ownership===

Collective ownership of code has several advantages of single ownership of code. The first is that no bottlenecks are created in the code base. If a change alters the dependencies in the code, any part of the code can be changed by any engineer on the team. Second, teams are bound to gain and lose members over the course of a project. Collective ownership is helpful in this case because a single engineer does not take a large portion of knowledge about the framework with him when he leaves. Additionally, new team members can ease into working on the code base without having a set of classes that they have never seen before assigned exclusively to them.

===Disadvantages of Collective Ownership===

Collective ownership is of course not perfect and comes with some disadvantages. First is that engineers tend to become attached to code that they have written. If other engineers on the team come in behind and overwrite large portions of code written by another engineer, that engineer may be upset by the alteration of his or her code.

Also collective ownership does not scale smoothly. Large teams, or teams working on large code bases, may run into problems if they attempt to use collective ownership of their code. Large teams run into problems because each engineer on a team is bound to have a slightly different vision of what the final product should look like and how it should behave. It is possible that time will be wasted as each developer adds his or her personal spin to each portion of the code, possibly overriding changes done by others.

===Unit Tests and Collective Ownership===

Collective ownership of code requires that an extensive test suite be present. Because engineers are allowed to change any part of the code base, they are likely to break some functionality without realizing it. This problem is mitigated by requiring that any altered code pass the test suite at 100% before it is committed. This ensures that no functionality is lost when a change is made to the system.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:46:15Z

Srmunill: /* Collective Ownership */

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:45:18Z

Srmunill: /* Disadvantages of Collective Ownership */

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-30T01:37:48Z

Srmunill: /* Collective Ownership */

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-29T20:33:33Z

Srmunill: /* Collective Ownership */

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-29T20:01:52Z

Srmunill: /* Continuous Integration */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|frame|Collective Ownership Workflow including Continuous Integration|thumb]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-29T20:00:15Z

Srmunill: /* Collective Ownership */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|frame|Collective Ownership Workflow including Continuous Integration|thumb]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-29T19:59:04Z

Srmunill: /* Collective Ownership */

== Collective Ownership ==

[[Image:Collective_ownership.GIF|100px|frame|Collective Ownership Workflow including Continuous Integration]]

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

File:Collective ownership.GIF

2007-11-29T19:54:07Z

Srmunill: From: http://www.extremeprogramming.org/map/code.html

From: http://www.extremeprogramming.org/map/code.html

CSC/ECE 517 Fall 2007/wiki3 4 sm

2007-11-27T01:49:15Z

Srmunill:

== Interface Segregation principle ==

The Interface Segregation principle states that

<blockquote>"Clients should not be forced to depend upon interfaces that they do not use."[1]</blockquote>

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

<blockquote>

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

[[Image:Interface_segregation_before.gif]]

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

[[Image:Interface_segregation_after.gif]]

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.
</blockquote>

The basic idea is that it is good practice to make sure that a single objuect (in this case, an interface) does not do too much. The more functionality that is put into an object, the harder it becomes to update that object when requirements change.

== References ==

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html

CSC/ECE 517 Fall 2007/wiki3 9 sm

2007-11-27T01:48:50Z

Srmunill:

== Collective Ownership ==

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

* All engineers use the same coding standards
* The project use code management tools to detect and resolve conflicts
* A comprehensive suite of unit tests exists
* Powerful browsing and refactoring tools to find references to old methods and replace them with the new
* Continuous Integration, so that conflicts are rare

The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

== Continuous Integration ==

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

== References ==

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-20T01:20:23Z

Srmunill:

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-20T00:40:17Z

Srmunill: /* Interface Segregation principle */

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-20T00:37:55Z

Srmunill: /* Interface Segregation principle */

== Interface Segregation principle ==

The Interface Segregation principle states that

<blockquote>"Clients should not be forced to depend upon interfaces that they do not use."[1]</blockquote>

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

<blockquote>

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

[[Image:Interface_segregation_before.gif]]

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

[[Image:Interface_segregation_after.gif]]

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.
</blockquote>

== References ==

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-20T00:37:04Z

Srmunill: /* Interface Segregation principle */

== Interface Segregation principle ==

The Interface Segregation principle states that

<blockquote>"Clients should not be forced to depend upon interfaces that they do not use."[1]</blockquote>

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

<blockquote>

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

[[Image:Interface_segregation_before.gif]]

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

[[Image:Interface_segregation_after.gif]]

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.
</blockquote>

== References ==

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html

File:Interface segregation after.gif

2007-11-20T00:35:21Z

Srmunill:

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-20T00:33:23Z

Srmunill: /* Interface Segregation principle */

== Interface Segregation principle ==

The Interface Segregation principle states that

<blockquote>"Clients should not be forced to depend upon interfaces that they do not use."[1]</blockquote>

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

<blockquote>

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

[[Image:Interface_segregation_before.gif]]

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

[[Image:Interface_segregation_after.gif]]

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.
</blockquote>

== References ==

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html

File:Interface segration after.gif

2007-11-20T00:32:23Z

Srmunill:

File:Interface segregation before.gif

2007-11-20T00:31:57Z

Srmunill:

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-20T00:31:11Z

Srmunill: /* Interface Segregation principle */

== Interface Segregation principle ==

The Interface Segregation principle states that

<blockquote>"Clients should not be forced to depend upon interfaces that they do not use."[1]</blockquote>

The interface segregation principle comes from a desire to avoid "fat" interfaces; interfaces whose methods can be divided into more than one group. This is very similar to the principle that a class should only do one thing and do it well.

An excellent example of why "fat" interfaces should be avoided is provided by DoodleProject:

<blockquote>

Recall the on-line bookseller system introduced in the Open-Closed Principle and referred to in the Dependency Inversion Principle. Now the company wants to start offering music CDs for sale through its website. To accommodate this, the search engine portion of the website will need to be modified. Trying to reuse as much code as possible, the SearchEngine and Query types are amended to accept CD searching queries. The resulting class diagram is:

[[Image:Example.jpg]]

To satisfy the requirements of CD searching, the Query interface was forced to handle both BookServletQuery and CDServletQuery functionality. In the future, if there is any change to the searching functionality of CDServletQuery, then that change will be forced onto the Query interface. Furthermore, any change to Query forces a change to all of its implementers, including BookServletQuery. This scenario, a change in the CD query portion of the website forces a change (and possible bugs) in the book query portion of the website, makes the software very fragile. To fix this BookServletQuery and CDServletQuery must be implemented from separate interfaces. This can easily be accomplished by adding some additional abstract types to the design that are more specific in their tasks. The new class diagram is:

[[Image:Example.jpg]]

With this design, the two functional concerns have been separated. Now, if CDServletQuery needs new searching functionality, the change is forced upon CDQuery but can not propagate to the book query portion of the design.
</blockquote>

== References ==

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

[2] http://www.objectmentor.com/resources/articles/isp.pdf

[3] http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-19T21:15:19Z

Srmunill: /* Interface Segregation principle */ Introduction to concept

== Interface Segregation principle ==

The Interface Segregation principle states that " Clients should not be forced to depend upon interfaces that they do not use."[1]

[1] http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html

CSC/ECE 506 Fall 2007/wiki3 4 sm

2007-11-19T21:08:47Z

Srmunill:

== Interface Segregation principle ==

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-19T19:17:17Z

Srmunill: /* Continuous Integration */ Expanded pros and cons

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-18T04:07:18Z

Srmunill: /* Continuous Integration */ Pros and Cons of Continuous Integration

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-18T03:16:17Z

Srmunill: /* Continuous Integration */ Intro to Continuous Intergration

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-18T02:56:12Z

Srmunill: /* Collective Ownership */ Added pros and cons of Collective Ownership

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-18T02:40:40Z

Srmunill: /* Collective Ownership */ Added introduction to Collective ownership

CSC/ECE 506 Fall 2007/wiki3 9 sm

2007-11-18T02:17:18Z

Srmunill: Created page with headers on the two required topics

== Collective Ownership ==

== Continuous Integration ==

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-14T21:45:27Z

Srmunill: /* Duck Typing */

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test, which can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.'' [1]

That is to say that, if object A displays the behavior of another object B, object A can be treated as if it was the same as object B. In computer science, this concept can be applied to the virtual objects used in object-oriented languages like Smalltalk, Java, and C#. In this case, "duck typing" is also known as unbounded polymorphism.

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run. [2]

This is in contrast to statically typed languages, such as Java. In these languages, if a parameter is passed to a method, that method my only use methods defined in that parameter or it's superclasses. If this rule is violated, an error is generated at compile time.

==Java Example==
Let us examine the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Duck Typing vs. Static Typing==

The most obvious advantage of duck typing over static typing is conciseness of code. In a statically typed language, more code is often required to ensure type safety. Another major advantage is that duck typing is less restrictive since it allows the the end user to choose what type of object will be passed as parameters to any method at run time. As long as that argument has the required behavior, the method will function properly.

The disadvantage of duck typing is the potential for errors to occur at run time when the program is out of the control of the programmer. In a statically typed language, type safety errors can be caught and corrected at compile time, before product release. As a result, statically typed languages are more suited for safety critical software, such as control systems. [3]

==See Also==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing.

For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx.

Dr. Ed Gehringer's notes on duck typing can be found at http://courses.ncsu.edu/csc517/common/lectures/notes/lec6.doc.

==References==

[1] http://en.wikipedia.org/wiki/Duck_test

[2] http://en.wikipedia.org/wiki/Duck_typing

[3] http://courses.ncsu.edu/csc517/common/lectures/notes/lec6.doc

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-14T17:15:54Z

Srmunill: /* Duck Typing */

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

Duck typing is also known as Unbounded Polymorphism.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Duck Typing vs. Static Typing==

The most obvious advantage of duck typing over static typing is conciseness of code. In a statically typed language, more code is often required to ensure type safety. Duck typing is less restrictive as it allows the user to choose what type of object will passed as parameters to any method. As long as that argument has that behavior, the method will function properly.

The disadvantage of duck typing is that potential errors will occur at run time, when the program is out of the control of the programmer. In a statically typed language, type safety error can be caught and corrected at compile time, before product release. As a result, statically typed languages are more suited for safety critical software, such as control systems.

==See Also==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T19:22:58Z

Srmunill: /* Duck Typing vs. Static Typing */

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Duck Typing vs. Static Typing==

The most obvious advantage of duck typing over static typing is conciseness of code. In a statically typed language, more code is often required to ensure type safety. Duck typing is less restrictive as it allows the user to choose what type of object will passed as parameters to any method. As long as that argument has that behavior, the method will function properly.

The disadvantage of duck typing is that potential errors will occur at run time, when the program is out of the control of the programmer. In a statically typed language, type safety error can be caught and corrected at compile time, before product release. As a result, statically typed languages are more suited for safety critical software, such as control systems.

==See Also==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T19:15:33Z

Srmunill: /* Other Examples and Discussion */

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Duck Typing vs. Static Typing==

The most obvious advantage of duck typing over static typing is conciseness of code. In a statically typed language, more code is often required to ensure type safety.

The disadvantage of duck typing is that potential errors will occur at run time, when the program is out of the control of the programmer. In a statically typed language, type safety error can be caught and corrected at compile time, before product release. As a result, statically typed languages are more suited for safety critical software, such as control systems.

==See Also==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T19:14:42Z

Srmunill: /* Advantages & Disadvantages */

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Duck Typing vs. Static Typing==

The most obvious advantage of duck typing over static typing is conciseness of code. In a statically typed language, more code is often required to ensure type safety.

The disadvantage of duck typing is that potential errors will occur at run time, when the program is out of the control of the programmer. In a statically typed language, type safety error can be caught and corrected at compile time, before product release. As a result, statically typed languages are more suited for safety critical software, such as control systems.

==Other Examples and Discussion==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T19:02:51Z

Srmunill:

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Advantages & Disadvantages==

Duck Typing Static Typing
Advantages Concise and elegant code

Less restrictive Safer (errors are caught at compile time)

Interfaces can ensure that certain methods are always defined
Disadvantages Potential errors at runtime (code cannot be monitored at runtime)

No guarantee that required methods are implemented in subclasses More verbose code is required to check for errors

==Other Examples and Discussion==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T19:01:59Z

Srmunill:

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Advantages & Disadvantages==

Duck Typing Static Typing
Advantages Concise and elegant code

Less restrictive Safer (errors are caught at compile time)

Interfaces can ensure that certain methods are always defined
Disadvantages Potential errors at runtime (code cannot be monitored at runtime)

No guarantee that required methods are implemented in subclasses More verbose code is required to check for errors

==Other Examples and Discussion==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T18:59:16Z

Srmunill:

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

In dynamically typed languages, such as Ruby, the parameters of a given method do not need to have a pre-specified type. At run time, if the argument passed to the parameter has the necessary methods, the code will run.

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters. The corrected, functional version of the MyMath class is shown below.

<code><pre>
class MyMath {
public static boolean equals(ImaginaryNumber a, ImaginaryNumber b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Advantages & Disadvantages==

Duck Typing Static Typing
Advantages Concise and elegant code

Less restrictive Safer (errors are caught at compile time)

Interfaces can ensure that certain methods are always defined
Disadvantages Potential errors at runtime (code cannot be monitored at runtime)

No guarantee that required methods are implemented in subclasses More verbose code is required to check for errors

==Other Examples and Discussion==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing

CSC/ECE 517 Fall 2007/wiki1 5 sl

2007-09-12T18:55:04Z

Srmunill:

= Duck Typing =

The term “duck typing” comes from the common American analogy of the duck test. This test can be summed up with the following phrase:

''If it walks like a duck and quacks like a duck, I would call it a duck.''[1]

==Java Example==
Take the following code snippet:

<code><pre>
class ImaginaryNumber extends Object {
public int realPart;
public int imaginaryPart;

public ImaginaryNumber(int realPart, int imaginaryPart) {
this.realPart = realPart;
this.imaginaryPart = imaginaryPart;
}

public int getRealPart() {
return realPart;
}

public int getImaginaryPart() {
return imaginaryPart;
}
}
</pre></code>

<code><pre>

class MyMath {
public static boolean equals(Object a, Object b) {
// this will create a compile-time error in Java
return (a.getRealPart() == b.getRealPart());
}
}
</pre></code>

In a non-duck typed language, such as Java, the Equals() method above has two parameters a and b. It is required that these parameters have a specific type, in this case “Object”. A compile-time error will be generated even if two ImaginaryNumber objects are passed to the method. This occurs in spite of the fact that ImaginaryNumber has definitions for all of the methods called in Equals() and that ImaginaryNumber is a subclass of Object. In order to correct this error, Equals() would have to be changed to take two ImaginaryNumber objects as parameters.

==Ruby Example==
In a duck typed language, such as Ruby, the Equals() method below would require parameters to have a defined type. A runtime error would be generated only if a non-ImaginaryNumber object was passed to the Equals() method. As long as only objects of type ImaginaryNumber are passed to the Equals() method, no error will ever be generated. The equivalent Ruby code is shown below.

<code><pre>
class ImaginaryNumber
def initialize(realPart, imaginaryPart)
@realPart = realPart
@imaginaryPart = imaginaryPart
end
attr_reader :realPart, :imaginaryPart
end

class MyMath
def self.equals(a, b)
a.realPart == b.realPart
end
end

</pre></code>
==Advantages & Disadvantages==

Duck Typing Static Typing
Advantages Concise and elegant code

Less restrictive Safer (errors are caught at compile time)

Interfaces can ensure that certain methods are always defined
Disadvantages Potential errors at runtime (code cannot be monitored at runtime)

No guarantee that required methods are implemented in subclasses More verbose code is required to check for errors

==Other Examples and Discussion==
For a more detailed example using Boo, a language that uses both static typing and duck typing, see http://boo.codehaus.org/Duck+Typing. For a real-world example of duck-typing in C#, visit http://haacked.com/archive/2007/08/19/why-duck-typing-matters-to-c-developers.aspx

==References==

[1] http://en.wikipedia.org/wiki/Duck_test
http://en.wikipedia.org/wiki/Duck_typing