Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 9 mdkt

2007-11-20T02:46:23Z

Kctreima:

===Note to reviewers:===
All prose on this page is original, unless otherwise credited. If you doubt this, please indicate the section that you feel is not original and the source from which you believe it was directly copied. Thank you.

=Assignment=
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

=Collective Ownership=
==Definition==
“Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.”

==Implications==
*Everyone owns all of the code
**Anyone can change any code anywhere
**No personal ownership of modules
**No egoless programming either
*Everyone is permitted access to all the code so everyone has a stake in knowing all of the code
*Requires deserved trust
*Communication is very important. If code is property of the whole team, comments are also used to enforce communication.

==Benefits==
*A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

*All code gets the benefit of many people's attention, which increases code quality and reduces defects

*Pair programming is usually used in conjunction with collective ownership: by working in different pairs, all the programmers get to see all the parts of the code. Pairing will be more difficult if the code any pair is working on is 'owned' by only one member. The non-owner of the pair may not feel comfortable suggesting or making changes to code that they don't have rights to. In collective ownership the code is ‘owned’ by everyone.

*It requires a lot of interaction (especially with pairing) and verbal communication. It would be difficult for a non-contributing programmer to hide out for long in this environment

===Problems with individual ownership that collective ownership addresses===
*When code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion. This is less likely to happen when every programmer is responsible for and has access to every piece of code.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

==Controversies==
*By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies

*The practice of quickly dipping into a related piece of code to make a quick change can be dangerous, because quick changes can often times create side-effect bugs.

*Collective ownership could be a problem if people worked blindly on code they did not understand.

*If only collective ownership, and not the other extreme programming practices of pair programming, testing, and coding standards, everyone’s efforts will end in chaos

*Pair programming and collective ownership does not bring out individual contributions (good or bad). Bonus plans and other types of performance rewards may have to be changed.

*Another concern with collective ownership is building expertise with the application. There are limits to the familiarity an individual can have with the codebase. Individual ownership helps solve this problem by limiting the amount of code a programmer creates to promote expertise in certain areas.

=Continuous Integration=
==Definition==
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." [http://martinfowler.com/articles/continuousIntegration.html -Martin Fowler]

==Examples==
The practice of Continuous Integration (CI) started as one of the twelve practices of Extreme Programming (XP). It is made up of several sub-practices:
#Programmers must commit their changes frequently to the repository (at least daily).
#Changes will invoke an automated build.
#The automated build must test the changes

These practices in turn generate (possibly) new dependencies:
#Use a version-controlled source code repository, such as Subversion or CVS
#Use a test framework, such as any of the XUnit frameworks.
#Use an automated tool to build several times per day (see below)

===Automated CI Tools===
These tools generally build the project at regular intervals. They also integrate with the version repository, report build success or failure, and often integrate with tools to report on test metrics.
*[http://cruisecontrol.sourceforge.net/index.html Cruise Control]
:The first and most popular Java-based tool
*[http://cruisecontrolrb.thoughtworks.com/ Cruise Control.rb]
:Cruise Control, the Ruby way
*[http://maven.apache.org/continuum Continuum]
:A CI tool used primarily in projects that use the Apache Maven build tool
*[http://code.google.com/p/vulcan/ Vulcan]
:Google's answer to CI

==Controversies==
As with most things, continuous integration has its benefits and drawbacks. The benefits far outweigh the drawbacks, though, so CI is adopted often even in projects that do not use other XP practices.[[#References|2, 3]]
===Benefits===
*Frequent commits ensure that everyone is using the latest version of the code (or as close to it as possible).
*Using a test framework ensures that the changes are tested whenever the project is built. More testing -> bugs are found (and fixed) sooner -> lower cost.
*Since much of the process is automated, team members are automatically kept informed of the state of the project.
*Studies show that undergraduate students who learn about CI have a deeper understanding of source code management (SCM)[[#References|4]]
===Drawbacks===
*Although CI is widely used in industry, it is rarely taught in academia.[[#References|5]]
*CI itself is nearly universally accepted as a good thing, but automated CI tools can be misused. Instead of taking the opportunity to speed up a slow build process, an automated CI tool can be abused as a crutch. Programmers rely on the tool to tell them that the build fails because of their changes, rather than ensuring (before commit) that their changes do not break the build.[[#References|6]]

=Conclusion=
Collective code ownership and continuous integration are two useful Agile practices taken from Extreme Programming, with each having benefits and drawbacks when paired (or not paired) with other Agile techniques. Collective ownership by itself is not very useful, but can be powerful when used in conjunction with other Agile practices. Continuous integration, though, can be very useful on its own. Collective ownership is good for small or less complex projects, but can be dangerous for large projects that require deep domain expertise. Continuous integration provides a framework to enhance the quality of software, but the use of automated tools can tempt programmers to become lazy, and not follow the practice as they should. When used properly, both practices can enhance the software development process.

=References=
#[http://martinfowler.com/articles/continuousIntegration.html Continuous Integration]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1151436&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Motivations and Measurements in an Agile Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1159759&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=6644938 Agile Customer Engagement: a Longitudinal Qualitative Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1134393&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=775368&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 What We Can Learn from Extreme Programming]
#[http://www.jamesshore.com/Blog/Why%20I%20Dont%20Like%20CruiseControl.html Why I Don't Like CruiseControl]

=See Also=
*[http://en.wikipedia.org/wiki/Continuous_integration Continuous Integration (Wikipedia)]
*[http://en.wikipedia.org/wiki/CruiseControl CruiseControl (Wikipedia)]

CSC/ECE 517 Fall 2007/wiki3 9 mdkt

2007-11-19T07:54:20Z

Kctreima: /* See Also */

===Note to reviewers:===
All prose on this page is original, unless otherwise credited. If you doubt this, please indicate the section that you feel is not original and the source from which you believe it was directly copied. Thank you.

=Assignment=
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

=Introduction=

=Collective Ownership=
==Definition==
“Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.”

==Implications==
*Everyone owns all of the code
**Anyone can change any code anywhere
**No personal ownership of modules
**No egoless programming either
*Everyone is permitted access to all the code so everyone has a stake in knowing all of the code
*Requires deserved trust
*Communication is very important. If code is property of the whole team, comments are also used to enforce communication.

==Benefits==
*A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

*All code gets the benefit of many people's attention, which increases code quality and reduces defects

*Pair programming is usually used in conjunction with collective ownership: by working in different pairs, all the programmers get to see all the parts of the code. Pairing will be more difficult if the code any pair is working on is 'owned' by only one member. The non-owner of the pair may not feel comfortable suggesting or making changes to code that they don't have rights to. In collective ownership the code is ‘owned’ by everyone.

*It requires a lot of interaction (especially with pairing) and verbal communication. It would be difficult for a non-contributing programmer to hide out for long in this environment

===Problems with individual ownership that collective ownership addresses===
*When code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion. This is less likely to happen when every programmer is responsible for and has access to every piece of code.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

==Controversies==
*By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies

*The practice of quickly dipping into a related piece of code to make a quick change can be dangerous, because quick changes can often times create side-effect bugs.

*Collective ownership could be a problem if people worked blindly on code they did not understand.

*If only collective ownership, and not the other extreme programming practices of pair programming, testing, and coding standards, everyone’s efforts will end in chaos

*Pair programming and collective ownership does not bring out individual contributions (good or bad). Bonus plans and other types of performance rewards may have to be changed.

*Another concern with collective ownership is building expertise with the application. There are limits to the familiarity an individual can have with the codebase. Individual ownership helps solve this problem by limiting the amount of code a programmer creates to promote expertise in certain areas.

=Continuous Integration=
==Definition==
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." [http://martinfowler.com/articles/continuousIntegration.html -Martin Fowler]

==Examples==
The practice of Continuous Integration (CI) started as one of the twelve practices of Extreme Programming (XP). It is made up of several sub-practices:
#Programmers must commit their changes frequently to the repository (at least daily).
#Changes will invoke an automated build.
#The automated build must test the changes

These practices in turn generate (possibly) new dependencies:
#Use a version-controlled source code repository, such as Subversion or CVS
#Use a test framework, such as any of the XUnit frameworks.
#Use an automated tool to build several times per day (see below)

===Automated CI Tools===
These tools generally build the project at regular intervals. They also integrate with the version repository, report build success or failure, and often integrate with tools to report on test metrics.
*[http://cruisecontrol.sourceforge.net/index.html Cruise Control]
:The first and most popular Java-based tool
*[http://cruisecontrolrb.thoughtworks.com/ Cruise Control.rb]
:Cruise Control, the Ruby way
*[http://maven.apache.org/continuum Continuum]
:A CI tool used primarily in projects that use the Apache Maven build tool
*[http://code.google.com/p/vulcan/ Vulcan]
:Google's answer to CI

==Controversies==
As with most things, continuous integration has its benefits and drawbacks. The benefits far outweigh the drawbacks, though, so CI is adopted often even in projects that do not use other XP practices.[[#References|2, 3]]
===Benefits===
*Frequent commits ensure that everyone is using the latest version of the code (or as close to it as possible).
*Using a test framework ensures that the changes are tested whenever the project is built. More testing -> bugs are found (and fixed) sooner -> lower cost.
*Since much of the process is automated, team members are automatically kept informed of the state of the project.
*Studies show that undergraduate students who learn about CI have a deeper understanding of source code management (SCM)[[#References|4]]
===Drawbacks===
*Although CI is widely used in industry, it is rarely taught in academia.[[#References|5]]
*CI itself is nearly universally accepted as a good thing, but automated CI tools can be misused. Instead of taking the opportunity to speed up a slow build process, an automated CI tool can be abused as a crutch. Programmers rely on the tool to tell them that the build fails because of their changes, rather than ensuring (before commit) that their changes do not break the build.[[#References|6]]

=Conclusion=

=References=
#[http://martinfowler.com/articles/continuousIntegration.html Continuous Integration]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1151436&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Motivations and Measurements in an Agile Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1159759&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=6644938 Agile Customer Engagement: a Longitudinal Qualitative Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1134393&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=775368&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 What We Can Learn from Extreme Programming]
#[http://www.jamesshore.com/Blog/Why%20I%20Dont%20Like%20CruiseControl.html Why I Don't Like CruiseControl]

=See Also=
*[http://en.wikipedia.org/wiki/Continuous_integration Continuous Integration (Wikipedia)]
*[http://en.wikipedia.org/wiki/CruiseControl CruiseControl (Wikipedia)]

CSC/ECE 517 Fall 2007/wiki3 9 mdkt

2007-11-19T07:51:03Z

Kctreima: /* Continuous Integration */

===Note to reviewers:===
All prose on this page is original, unless otherwise credited. If you doubt this, please indicate the section that you feel is not original and the source from which you believe it was directly copied. Thank you.

=Assignment=
Two of the important Agile methodologies that we have not said much about in this course are collective ownership and continuous integration. What are the best definitions or examples you can find? Are these widely practiced? Are they controversial? Are there adherents of other design methodologies who consider them harmful? Investigate, through the Web and through the ACM DL.

=Introduction=

=Collective Ownership=
==Definition==
“Collective code ownership means that everybody is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.”

==Implications==
*Everyone owns all of the code
**Anyone can change any code anywhere
**No personal ownership of modules
**No egoless programming either
*Everyone is permitted access to all the code so everyone has a stake in knowing all of the code
*Requires deserved trust
*Communication is very important. If code is property of the whole team, comments are also used to enforce communication.

==Benefits==
*A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

*All code gets the benefit of many people's attention, which increases code quality and reduces defects

*Pair programming is usually used in conjunction with collective ownership: by working in different pairs, all the programmers get to see all the parts of the code. Pairing will be more difficult if the code any pair is working on is 'owned' by only one member. The non-owner of the pair may not feel comfortable suggesting or making changes to code that they don't have rights to. In collective ownership the code is ‘owned’ by everyone.

*It requires a lot of interaction (especially with pairing) and verbal communication. It would be difficult for a non-contributing programmer to hide out for long in this environment

===Problems with individual ownership that collective ownership addresses===
*When code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion. This is less likely to happen when every programmer is responsible for and has access to every piece of code.
*Individuals could become singularly responsible for specific areas of the project in individual ownership. This can pose a problem when any one individual leaves the project. The degree to which this may affect the project varies, depending on how well the individual has documented the program and on how much time there is to get somebody else trained before the individual leaves. When everyone has a stake in knowing every piece of code, as in a collective ownership scenario, this danger is less.
*Another problem is that modules that are too insular may become ‘miniprojects’ consisting of just a few developers each. Each miniproject may have its own set of coding styles, designs, politics, feature wars, and preferred technologies. Integrating these miniprojects into one collective, consistent product might prove to be impossible, depending how much they have been allowed to diverge. The problem worsens when the project scales up, particularly when not all the developers will fit into one room. In collective ownership the likelihood of very divergent coding practices amongst different groups is less likely.
*When only specific individuals are familiar with certain portions of the codebase, others on the team can be held up waiting for changes to be made. In addition, the amount of work needed for different sections of a project can change during the course of development. If individual ownership of each section is promoted too much, work loads can become lopsided

==Controversies==
*By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies

*The practice of quickly dipping into a related piece of code to make a quick change can be dangerous, because quick changes can often times create side-effect bugs.

*Collective ownership could be a problem if people worked blindly on code they did not understand.

*If only collective ownership, and not the other extreme programming practices of pair programming, testing, and coding standards, everyone’s efforts will end in chaos

*Pair programming and collective ownership does not bring out individual contributions (good or bad). Bonus plans and other types of performance rewards may have to be changed.

*Another concern with collective ownership is building expertise with the application. There are limits to the familiarity an individual can have with the codebase. Individual ownership helps solve this problem by limiting the amount of code a programmer creates to promote expertise in certain areas.

=Continuous Integration=
==Definition==
"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible." [http://martinfowler.com/articles/continuousIntegration.html -Martin Fowler]

==Examples==
The practice of Continuous Integration (CI) started as one of the twelve practices of Extreme Programming (XP). It is made up of several sub-practices:
#Programmers must commit their changes frequently to the repository (at least daily).
#Changes will invoke an automated build.
#The automated build must test the changes

These practices in turn generate (possibly) new dependencies:
#Use a version-controlled source code repository, such as Subversion or CVS
#Use a test framework, such as any of the XUnit frameworks.
#Use an automated tool to build several times per day (see below)

===Automated CI Tools===
These tools generally build the project at regular intervals. They also integrate with the version repository, report build success or failure, and often integrate with tools to report on test metrics.
*[http://cruisecontrol.sourceforge.net/index.html Cruise Control]
:The first and most popular Java-based tool
*[http://cruisecontrolrb.thoughtworks.com/ Cruise Control.rb]
:Cruise Control, the Ruby way
*[http://maven.apache.org/continuum Continuum]
:A CI tool used primarily in projects that use the Apache Maven build tool
*[http://code.google.com/p/vulcan/ Vulcan]
:Google's answer to CI

==Controversies==
As with most things, continuous integration has its benefits and drawbacks. The benefits far outweigh the drawbacks, though, so CI is adopted often even in projects that do not use other XP practices.[[#References|2, 3]]
===Benefits===
*Frequent commits ensure that everyone is using the latest version of the code (or as close to it as possible).
*Using a test framework ensures that the changes are tested whenever the project is built. More testing -> bugs are found (and fixed) sooner -> lower cost.
*Since much of the process is automated, team members are automatically kept informed of the state of the project.
*Studies show that undergraduate students who learn about CI have a deeper understanding of source code management (SCM)[[#References|4]]
===Drawbacks===
*Although CI is widely used in industry, it is rarely taught in academia.[[#References|5]]
*CI itself is nearly universally accepted as a good thing, but automated CI tools can be misused. Instead of taking the opportunity to speed up a slow build process, an automated CI tool can be abused as a crutch. Programmers rely on the tool to tell them that the build fails because of their changes, rather than ensuring (before commit) that their changes do not break the build.[[#References|6]]

=Conclusion=

=References=
#[http://martinfowler.com/articles/continuousIntegration.html Continuous Integration]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1151436&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Motivations and Measurements in an Agile Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1159759&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=6644938 Agile Customer Engagement: a Longitudinal Qualitative Case Study]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=1134393&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 Assessing Undergraduate Experience of Continuous Integration and Test-Driven Development]
#[http://www.lib.ncsu.edu:2162/ft_gateway.cfm?id=775368&type=pdf&coll=portal&dl=ACM&CFID=43728495&CFTOKEN=66449388 What We Can Learn from Extreme Programming]
#[http://www.jamesshore.com/Blog/Why%20I%20Dont%20Like%20CruiseControl.html Why I Don't Like CruiseControl]

=See Also=

CSC/ECE 517 Fall 2007/wiki3 9 mdkt

2007-11-19T07:45:13Z

Kctreima: /* References */

CSC/ECE 517 Fall 2007/wiki3 9 mdkt

2007-11-18T16:09:38Z

Kctreima:

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-28T13:59:19Z

Kctreima:

===Note to reviewers:===
All prose on this page is original, unless otherwise cited. If you doubt this, please provide the source from which you think it was copied. Thank you.
=Assignment=
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

=Introduction=
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

==MVC Architecture==

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

==Ruby on Rails==

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

==Apache Struts==

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

=Comparison of Ruby on Rails and Apache Struts=

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model-View-Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

=Advantages=

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

==Advantages for the Developer==

===Rails advantages for the developer===
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

===Struts advantages for the developer===
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*When comparing popular job search sites, employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12, 13, 14]]

==Advantages for the Final Application==

===Rails advantages for the final application===
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

===Struts advantages for the final application===
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|15]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|16]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|17]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

=Conclusion=
Rails and Struts each have their own strengths and weaknesses. Rails lends itself to simple designs, rapid development, and improved maintainability. Struts excels in areas of performance, scalability, and internationalization. If one is trying to make an architecture choice for a project, many other considerations must be also taken into account, such as staffing, support, and other economic issues beyond the scope of this technical review.

=References=

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://jobsearch.monster.com/Search.aspx?q=struts&fn=&lid=&re=130&cy=us&brd=1&JSNONREG=1 Monster.com - Job postings for Struts]
#[http://jobsearch.monster.com/Search.aspx?q=rails&fn=&lid=&re=130&cy=us&brd=1&JSNONREG=1 Monster.com - Job postings for Rails]
#[http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&FREE_TEXT=struts Dice.com - Job postings for Struts]
#[http://seeker.dice.com/jobsearch/servlet/JobSearch?op=300&FREE_TEXT=rails Dice.com - Job postings for Rails]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

=See Also=
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-28T13:37:52Z

Kctreima:

===Note to reviewers:===
All prose on this page is original, unless otherwise cited. If you doubt this, please provide the source from which you think it was copied. Thank you.
=Assignment=
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

=Introduction=
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

==MVC Architecture==

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

==Ruby on Rails==

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

==Apache Struts==

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

=Comparison of Ruby on Rails and Apache Struts=

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model-View-Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

=Advantages=

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

==Advantages for the Developer==

===Rails advantages for the developer===
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

===Struts advantages for the developer===
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12]]

==Advantages for the Final Application==

===Rails advantages for the final application===
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

===Struts advantages for the final application===
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|13]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|14]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|15]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

=Conclusion=
Rails and Struts each have their own strengths and weaknesses. Rails lends itself to simple designs, rapid development, and improved maintainability. Struts excels in areas of performance, scalability, and internationalization. If one is trying to make an architecture choice for a project, many other considerations must be also taken into account, such as staffing, support, and other economic issues beyond the scope of this technical review.

=References=

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

=See Also=
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T02:51:30Z

Kctreima: /* Advantages for the Final Application */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model-View-Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12]]

===Advantages for the Final Application===

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|13]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|14]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|15]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==Conclusion==
Rails and Struts each have their own strengths and weaknesses. Rails lends itself to simple designs, rapid development, and improved maintainability. Struts excels in areas of performance, scalability, and internationalization. If one is trying to make an architecture choice for a project, many other considerations must be also taken into account, such as staffing, support, and other economic issues beyond the scope of this technical review.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T02:50:39Z

Kctreima:

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model-View-Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12]]

===Advantages for the Final Application===

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|13]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|14]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|15]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==Conclusion==
Rails and Struts each have their own strengths and weaknesses. Rails lends itself to simple designs, rapid development, and improved maintainability. Struts excels in areas of performance, scalability, and internationalization. If one is trying to make an architecture choice for a project, many other considerations must be also taken into account, such as staffing, support, and other economic issues beyond the scope of this technical review.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T02:11:18Z

Kctreima: /* References */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12]]

===Advantages for the Final Application===

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|13]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|14]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|15]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T02:05:43Z

Kctreima: /* Advantages */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintenance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|11, 12]]

===Advantages for the Final Application===

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, zero configuration files, and Rails' DRY mantra make maintenance easier since there is less code to maintain, and it is more easily understood.
*Since Rails includes almost everything you need for a web application (and there are packages readily available that include the missing pieces), there are fewer moving parts, leading to simpler designs, and therefore, again, a more maintainable solution.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|13]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|14]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.[[#References|15]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T01:53:12Z

Kctreima: /* References */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|13, 14]]

===Advantages for the Final Application===
'''to do: add internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, and zero configuration files make maintenance easier since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|11]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|12]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://wiki.rubyonrails.org/rails/pages/Internationalization Internationalization in Ruby on Rails]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T01:51:13Z

Kctreima: /* Advantages */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|13, 14]]

===Advantages for the Final Application===
'''to do: add internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, and zero configuration files make maintenance easier since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|11]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|12]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Rails offers no support for internationalization.
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T01:38:03Z

Kctreima: /* Advantages for the Final Application */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, and zero configuration files make maintenance easier since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Java has been shown to be faster than Ruby in many performance benchmark tests.[[#References|11]]
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|12]]
*Complementary technologies related to scalability (fast web servers, clustering, etc.) have evolved significantly in the last two years for RoR, but do not yet reach the maturity level of corresponding technologies for Java/Struts.
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T00:36:07Z

Kctreima: /* References */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add scalability, internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, and zero configuration files make maintainance easier since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|11]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://shootout.alioth.debian.org/ The Computer Language Benchmarks Game]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-25T00:34:38Z

Kctreima: /* Advantages for the Final Application */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add scalability, internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby on Rails, such as a smaller code footprint, more readable and elegant code, and zero configuration files make maintainance easier since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|11]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-24T06:38:42Z

Kctreima: /* Advantages */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add scalability, internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby, such as a smaller code footprint, more readable and elegant code, make maintainance easier (from the programmer's perspective) since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|11]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-24T06:37:05Z

Kctreima: /* References */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

'''note: lots of good stuff in here to include: http://rewrite.rickbradley.com/pages/moving_to_rails/'''

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add scalability, internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby, such as a smaller code footprint, more readable and elegant code, make maintainance easier (from the programmer's perspective) since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|11]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://rewrite.rickbradley.com/pages/moving_to_rails/ Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite]
#[http://www.theserverside.com/tt/articles/article.tss?l=RailsHibernate Hibernate vs. Rails: The Persistence Showdown]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-24T06:14:59Z

Kctreima: /* Advantages */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

'''note: lots of good stuff in here to include: http://rewrite.rickbradley.com/pages/moving_to_rails/'''

===Advantages for the Developer===

Rails offers the following advantages for the developer:
*Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.
*Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.
*Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.
*Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.
*Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.
*Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.

Struts offers the following advantages for the developer:
*With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.
*Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.
*Commercial support is more widely available in the Java community.[[#References|10]]
*Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|12, 13]]

===Advantages for the Final Application===
'''to do: add scalability, internationalization'''

Rails offers the following advantages for the final application:
*URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.
*Some of the virtues of Ruby, such as a smaller code footprint, more readable and elegant code, make maintainance easier (from the programmer's perspective) since there is less code to maintain, and it is more easily understood.

Struts offers the following advantages for the final application:
*Struts is an older and more established framework, and is a proven technology.
*Though Struts itself does not offer a persistence framework, it is often paired with Hibernate. Hibernate offers performance advantages over ActiveRecord, particularly when dealing with complex data models using outer joins.[[#References|11]]
*Since there are currently more Struts developers than Rails developers, staffing is easier, which lends itself to easier maintenance from a manager's perspective.

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-24T04:43:53Z

Kctreima: /* References */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

'''note: lots of good stuff in here to include: http://rewrite.rickbradley.com/pages/moving_to_rails/'''

===Advantages for the Developer===

Rails offers the following advantages for the developer:

<ul>
<li>Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.</li>
<li>Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.</li>
<li>Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.</li>
<li>Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.</li>
</ul>

Struts offers the following advantages for the developer:

<ul>
<li>Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.</li>
<li>Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|10, 11]]</li>
</ul>

===Advantages for the Final Application===
'''to do: add scalability, performance, internationalization, what else?'''

Rails offers the following advantages for the final application:
<ul>
<li>reword: less config, less repetition in code, generated core code on fly makes for smaller app, etc</li>
<li>Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.</li>
<li>Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.</li>
<li>URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.</li>
</ul>

Struts offers the following advantages for the final application:
<ul>
<li>Struts is an older and more established framework, and is a proven technology.</li>
<li>With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.</li>
</ul>

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]
#[http://www.monster.com/ Monster.com]
#[http://www.dice.com/ Dice.com]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki2 1 rl

2007-10-24T04:41:49Z

Kctreima: /* Advantages for the Developer */

==Assignment==
Compare Ruby on Rails with Apache Struts. The Apache Struts framework in the Java world occupies a position similar to Ruby on Rails, except that it is not as universally used. Compare the two. Which are the advantages of each for the developer? For the finished application?

==Introduction==
Ruby on Rails and Apache Struts are both web application frameworks based on the Model-View-Controller (MVC) architecture.

===MVC Architecture===

MVC separates an application into three components: the ''model'', the ''view'', and the ''controller''. The model maintains the application state; it consists of both the data used by the application as well as the rules surrounding the use of that data. The view generates the user interface, which allows the user to view and interact with the data in the model. The controller takes input from the outside world, interprets the input, and manipulates the model accordingly. Separating these three components, or concerns, makes the application code easier to understand, reuse, and maintain.

===Ruby on Rails===

Ruby on Rails, also known as "Rails" or "RoR", is the standard Web application framework for the Ruby programming language. It is an open source project that was released in 2004, and was created to make web application development quick and easy.

All Rails applications use the MVC architecture. Rails projects are created with a placeholder for each concern, and these concerns always interact in the same standard way. Models and controllers are Ruby classes, and views are written in eRuby (HTML with embedded Ruby). The Ruby router directs requests to a particular controller and action based on the URL.

For more basic information on Ruby on Rails, visit the [http://www.rubyonrails.org/ Ruby on Rails homepage].

===Apache Struts===

Apache Struts is a Web application framework for the Java programming language, used to create Java 2 Platform, Enterprise Edition (J2EE) applications. It is an open source project that was donated to Apache in 2000. Struts was introduced to encourage the use of the MVC architecture. Struts provides a controller in the way of request and response handlers, and provides a tag library that developers can use to develop views. The model is left up to the developer.

For more basic information on Apache Struts, visit the [http://struts.apache.org/ Apache Struts homepage].

==Comparison of Ruby on Rails and Apache Struts==

Rails and Struts are similar in many ways. They are both web application frameworks for their respective languages, and they both implement the Model View Controller architecture. The figure below, taken from [http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?], provides a comparison of a typical Rails stack and a typical J2EE stack containing Struts.

[[Image:stack.jpg]]

As you can see, the two stacks are fundamentally quite similar. Note, however, that the Persistence (Model) layer of the Rails stack, Active Record, is actually part of the Rails framework, whereas Hibernate (an object-relational mapper for Java) is not part of Struts. This is one key difference between Rails and Struts: Rails provides a complete MVC implementation and Struts does not. In addition to not providing a Model implementation, Struts also does not fully provide a View. As you can see in the stack, JSPs are used for the View, and these JSPs take advantage of a tag library provided by Struts.

In Rails, the DispatchServlet dispatches web requests to the controller and action specified in the URL. For example, a request for a URL ending in /questions/show/3 will be routed to the QuestionsController class and the show method. By convention, Rails knows that this will be found in questions_controller.rb. Assuming scaffolding is in use and no customization has been done to change the behavior, this url will cause the question with ID of 3 to be displayed to the end user. The ActionServlet in Struts, on the other hand, uses an XML configuration file to map requests to specific controllers and actions. This typifies another key difference between Rails and Struts: Where Rails relies on convention, reflection and discovery to determine what to do, Struts relies on configuration files. Note also that actions in Rails are simply methods inside their respective controllers, but they require full classes in Struts.

==Advantages==

Both Rails and Struts offer all the advantages that come with using the MVC architecture. The separation of concerns makes the code more maintainable, reusable, and understandable. It allows developers to specialize, and facilitates parallel development. Finally, it makes enhancements to the application easier to design and implement. The two frameworks each also offer distinct advantages over the other, both for the developer and for the finished application.

'''note: lots of good stuff in here to include: http://rewrite.rickbradley.com/pages/moving_to_rails/'''

===Advantages for the Developer===

Rails offers the following advantages for the developer:

<ul>
<li>Rails can be installed in minutes, and a fully-functional skeleton application can be created and running in seconds.</li>
<li>Rails provides database scaffolding out of the box. Essentially, Rails will generate all of the code necessary to do basic database interactions, such as create, read, update, and delete entries. This allows developers to quickly and easily begin working with their data model, and replace the generated code with customized versions piece by piece.</li>
<li>Rails favors ''Convention over Configuration.'' Rails uses sensible defaults, so as long as you follow convention, your application can be written with significantly less code and without the great number of configuration files seen in other web applications today. For example, if you create a model class called ''Product'', Rails will also generate for you a controller class named ''ProductsController'', and will assume that your model is using a database table called ''products''. You only need to configure the table name if you are using a different value. Writing less code and doing less configuration saves developers time during design, development, test, and maintentance.</li>
<li>Rails has ''Don't Repeat Yourself'' as its mantra. Information about the system should be expressed in only one place. For example, the names of the columns of a database table need only be contained in the table itself. Rails gathers this information through reflection and discovery. Avoiding code repetition is always good for the developer.</li>
</ul>

Struts offers the following advantages for the developer:

<ul>
<li>Java/Struts/J2EE has significantly more and better tooling available than Ruby/Rails.</li>
<li>Employment opportunities for Struts are of an order of magnitude greater than those for Rails.[[#References|10, 11]]</li>
</ul>

===Advantages for the Final Application===
'''to do: add scalability, performance, internationalization, what else?'''

Rails offers the following advantages for the final application:
<ul>
<li>reword: less config, less repetition in code, generated core code on fly makes for smaller app, etc</li>
<li>Rails natively supports filters, which allow you to wrap actions with before-code and after-code, for concerns such as authentication, logging, etc. Struts, on the other hand, requires SAIF (Struts Action Invocation Framework) in order to support filters.</li>
<li>Rails natively supports layouts for a common look and feel. Struts on the other hand requires the use of Tiles (a separate Apache project) to do the same, and this in turn necessitates even more XML configuration.</li>
<li>URLs in a Rails application are short and clear. They are of the form <nowiki>http://host:port/controller/action/id</nowiki>. Default Struts, on the other hand, exposes the use of Struts to the user by showing *.do at the end of the URL.</li>
</ul>

Struts offers the following advantages for the final application:
<ul>
<li>Struts is an older and more established framework, and is a proven technology.</li>
<li>With Struts, you are not locked into a specific model implementation. You can select a model implementation that best suits your application's needs.</li>
</ul>

==References==

#[http://www.ibm.com/developerworks/linux/library/wa-rubyonrails/ Ruby on Rails and J2EE: Is there room for both?]
#[http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails-revisited.html Rolling with Ruby on Rails Revisited]
#[http://www.rubyonrails.org/ Ruby on Rails]
#[http://en.wikipedia.org/wiki/Model-view-controller Model-view-controller]
#[http://www.csc.ncsu.edu/faculty/gehringer/517/f07/material/index.php CSC517 Lecture 12: Ruby on Rails]
#[http://www.pragprog.com/titles/rails2 Agile Web Development with Rails]
#[http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails Wikipedia entry]
#[http://en.wikipedia.org/wiki/Struts Apache Struts Wikipedia entry]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/115595 Rails vs Java Struts]

==See Also==
#[http://www.hibernate.org/ Hibernate]
#[http://struts.sourceforge.net/saif/index.html SAIF]
#[http://tiles.apache.org/ Apache Tiles]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T21:44:25Z

Kctreima:

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class [[#References|3]]. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. In Java the Attack is an interface that must be implemented as concrete classes, and in Ruby, the attack is a Proc object which encapsulates a behavior [[#References|4]]. Specific attacks are implemented as modules with which to extend a fighter [[#References|6]]. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Boxer b = new Boxer();
Wrestler w = new Wrestler();
Fighter[] fighters = { b, w };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
b.setAttack(new RoundhouseKick());
w.setAttack(new LegSweep());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, using its block construct and Proc objects it is possible to eliminate the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby allows new attack behaviors to be created on the fly at run time in addition to being included as modules at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

#Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
#Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
#Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004, p.34
#CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007, p.4
#[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
#[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
#[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T20:32:57Z

Kctreima: /* Succinctness */

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Boxer b = new Boxer();
Wrestler w = new Wrestler();
Fighter[] fighters = { b, w };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
b.setAttack(new RoundhouseKick());
w.setAttack(new LegSweep());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, using its block construct and Proc objectsit is possible to eliminate the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby allows new attack behaviors to be created on the fly at run time in addition to being included as modules at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T20:28:08Z

Kctreima: /* Clarity */

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Boxer b = new Boxer();
Wrestler w = new Wrestler();
Fighter[] fighters = { b, w };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
b.setAttack(new RoundhouseKick());
w.setAttack(new LegSweep());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T20:08:39Z

Kctreima: /* Java */

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Boxer b = new Boxer();
Wrestler w = new Wrestler();
Fighter[] fighters = { b, w };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
b.setAttack(new RoundhouseKick());
w.setAttack(new LegSweep());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T19:50:51Z

Kctreima: /* Java */

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Boxer b = new Boxer();
Wrestler w = new Wrestler();
Fighter[] fighters = { b, w };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
b.setAttack(new LegSweep());
w.setAttack(new RoundhouseKick());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-10T19:48:35Z

Kctreima: /* Ruby */

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem found in software development. Often during the development of a class, behaviors and algorithms (the strategies) can become mixed into the class while implementing without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through [http://www.gotw.ca/publications/mill06.htm inheritance], but over time this could result in an overly complex class hierarchy. The strategy pattern is a design pattern that can be used to [http://courses.csail.mit.edu/6.170/old-www/2002-Fall/lectures/lecture-09.pdf decouple] the behavior and algorithms (the strategy) from the object being acted upon (the context).

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]
The general structure of the strategy design pattern has a context class which contains a reference to the strategy class’s behavior interface. The context class can instantiate whichever behavior that it needs statically or at runtime. This design provides much weaker coupling between the context and behavior than if different context classes were derived for each type of behavior.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four ("[http://hillside.net/patterns/DPBook/DPBook.html Design Patterns] – Elements of Reusable Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://martinfowler.com/books.html#refactoring Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many similar behaviors or uses different variations of the same algorithm. Instead of using conditional statements within the class to select the behavior or algorithm, use the strategy pattern to take advantage of polymorphism.
#A class that uses data structures related to a behavior of the class but not the class itself. The strategy pattern can encapsulate the data specific to the behavior.
#Many similar classes that differ only in a type of behavior. These classes can be combined into a single class with the behavior refactored into separate classes so that the behavior can be selected by the instantiated class.

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
#A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern instead when the state of the object changes with a change in behavior.
Use the bridge pattern instead when a structural design is needed.
Use the command pattern instead when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Fighter[] fighters = { new Boxer(), new Wrestler() };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
fighters[0].setAttack(new LegSweep());
fighters[1].setAttack(new RoundhouseKick());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
# The Judo player will attack with a leg sweep by default
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
# The kickboxer will attack with a roundhouse kick by default
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
# The boxer will attack with a jab by default
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
# The wrestler will attack with a shoot in by default
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
# Fight three rounds
rounds = 3
# Create two fighters with default attack types
b = Boxer.new
w = Wrestler.new
fighters = [ b, w ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# Now swap in new behaviors
b.attack = Proc.new { puts "Front Kick!" }
include LegSweep
w.attack = Proc.new { leg_sweep }
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995, pp. 315-323
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-09T22:26:26Z

Kctreima:

==The Question==
Take a case of the Strategy pattern and implement it as succinctly as possible in Ruby and Java. Compare the two implementations in terms of clarity and succinctness. The example should be a "real-world" example. While it may be grossly oversimplified for the purpose of illustration, it should not be totally contrived (i.e., should not raise the question, Why would anyone ever want to do that?).

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes, behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from the object being acted upon.

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://www.refactoring.com/ Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
#A class that exhibits many behaviors</li>
#A class that uses many variations of an algorithm</li>
#A class that uses data structures related to a behavior but not the class</li>
#Many similar classes that differ only in a type of behavior</li>

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
#Allows classes to change behavior at runtime or design time</li>
#Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]</li>
#Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]</li>
#A well known design pattern communicates the intent of the code more readily</li>

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
// This method sets the fighter's default attack,
// which will be different for each type of fighter
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
// The JudoPlayer will execute a LegSweep by default
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
// The KickBoxer will execute a RoundhouseKick by default
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
// The Boxer will execute a Jab by default
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
// The Wrestler will execute a ShootIn by default
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
// Create two fighters with default attack types
Fighter[] fighters = { new Boxer(), new Wrestler() };
// Fight three rounds
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
// Now swap in new behaviors
fighters[0].setAttack(new LegSweep());
fighters[1].setAttack(new RoundhouseKick());
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(technique)
@attack = technique
end
def fight
@attack.execute
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
def initialize
# The JudoPlayer will execute a LegSweep by default
super(LegSweep.new)
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
def initialize
# The KickBoxer will execute a RoundhouseKick by default
super(RoundhouseKick.new)
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
def initialize
# The Boxer will execute a Jab by default
super(Jab.new)
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
def initialize
# The Wrestler will execute a ShootIn by default
super(ShootIn.new)
end
end

RoundhouseKick.rb:
class RoundhouseKick
def execute
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
class ShootIn
def execute
puts "Shoot In!"
end
end

LegSweep.rb:
class LegSweep
def execute
puts "Leg Sweep!"
end
end

Jab.rb:
class Jab
def execute
puts "Jab!"
end
end

Fight.rb:
# Create two fighters with default attack types
rounds = 3
fighters = [ JudoPlayer.new, KickBoxer.new ]
# Fight three rounds
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# now swap in new behaviors
fighters[0].attack = ShootIn.new
fighters[1].attack = Jab.new
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-02T01:41:51Z

Kctreima: /* Succinctness */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes, behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from the object being acted upon.

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://www.refactoring.com/ Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
<ol>
<li> A class that exhibits many behaviors</li>
<li> A class that uses many variations of an algorithm</li>
<li> A class that uses data structures related to a behavior but not the class</li>
<li> Many similar classes that differ only in a type of behavior</li>
</ol>

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
<ol>
<li> Allows classes to change behavior at runtime or design time</li>
<li> Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]</li>
<li> Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]</li>
<li> A well known design pattern communicates the intent of the code more readily</li>
</ol>

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(technique)
@attack = technique
end
def fight
@attack.execute
end
end

MethodMissing.rb
module MissingMethod
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
class JudoPlayer < Fighter
def initialize(technique)
super(technique)
end
end

KickBoxer.rb:
require 'Fighter'
class KickBoxer < Fighter
def initialize(technique)
super(technique)
end
end

Boxer.rb:
require 'Fighter'
class Boxer < Fighter
def initialize(technique)
super(technique)
end
end

Wrestler.rb:
require 'Fighter'
class Wrestler < Fighter
def initialize(technique)
super(technique)
end
end

RoundhouseKick.rb:
require 'MethodMissing'
class RoundhouseKick
include MethodMissing
def execute
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
require 'MethodMissing'
class ShootIn
include MethodMissing
def execute
puts "Shoot In!"
end
end

LegSweep.rb:
require 'MethodMissing'
class LegSweep
include MethodMissing
def execute
puts "Leg Sweep!"
end
end

Jab.rb:
require 'MethodMissing'
class Jab
include MethodMissing
def execute
puts "Jab!"
end
end

Fight.rb:
# Create two fighters assigning initial attack types
rounds = 3
fighters = [ JudoPlayer.new(LegSweep.new), KickBoxer.new(RoundhouseKick.new) ]
# Fight three rounds
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# now swap in new behaviors
fighters[0].attack = ShootIn.new
fighters[1].attack = Jab.new
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-02T01:39:11Z

Kctreima: /* Comparison of Implementations */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes, behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from the object being acted upon.

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://www.refactoring.com/ Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
<ol>
<li> A class that exhibits many behaviors</li>
<li> A class that uses many variations of an algorithm</li>
<li> A class that uses data structures related to a behavior but not the class</li>
<li> Many similar classes that differ only in a type of behavior</li>
</ol>

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
<ol>
<li> Allows classes to change behavior at runtime or design time</li>
<li> Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]</li>
<li> Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]</li>
<li> A well known design pattern communicates the intent of the code more readily</li>
</ol>

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(technique)
@attack = technique
end
def fight
@attack.execute
end
end

MethodMissing.rb
module MissingMethod
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
class JudoPlayer < Fighter
def initialize(technique)
super(technique)
end
end

KickBoxer.rb:
require 'Fighter'
class KickBoxer < Fighter
def initialize(technique)
super(technique)
end
end

Boxer.rb:
require 'Fighter'
class Boxer < Fighter
def initialize(technique)
super(technique)
end
end

Wrestler.rb:
require 'Fighter'
class Wrestler < Fighter
def initialize(technique)
super(technique)
end
end

RoundhouseKick.rb:
require 'MethodMissing'
class RoundhouseKick
include MethodMissing
def execute
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
require 'MethodMissing'
class ShootIn
include MethodMissing
def execute
puts "Shoot In!"
end
end

LegSweep.rb:
require 'MethodMissing'
class LegSweep
include MethodMissing
def execute
puts "Leg Sweep!"
end
end

Jab.rb:
require 'MethodMissing'
class Jab
include MethodMissing
def execute
puts "Jab!"
end
end

Fight.rb:
# Create two fighters assigning initial attack types
rounds = 3
fighters = [ JudoPlayer.new(LegSweep.new), KickBoxer.new(RoundhouseKick.new) ]
# Fight three rounds
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# now swap in new behaviors
fighters[0].attack = ShootIn.new
fighters[1].attack = Jab.new
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be).

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, once the framework of the design is in place, there are many features of the Ruby language that could be used to make the implementation more concise than than the Java version. For example, Ruby offers a means to simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-02T01:25:04Z

Kctreima: /* Ruby */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes, behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from the object being acted upon.

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://www.refactoring.com/ Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
<ol>
<li> A class that exhibits many behaviors</li>
<li> A class that uses many variations of an algorithm</li>
<li> A class that uses data structures related to a behavior but not the class</li>
<li> Many similar classes that differ only in a type of behavior</li>
</ol>

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
<ol>
<li> Allows classes to change behavior at runtime or design time</li>
<li> Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]</li>
<li> Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]</li>
<li> A well known design pattern communicates the intent of the code more readily</li>
</ol>

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(technique)
@attack = technique
end
def fight
@attack.execute
end
end

MethodMissing.rb
module MissingMethod
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
class JudoPlayer < Fighter
def initialize(technique)
super(technique)
end
end

KickBoxer.rb:
require 'Fighter'
class KickBoxer < Fighter
def initialize(technique)
super(technique)
end
end

Boxer.rb:
require 'Fighter'
class Boxer < Fighter
def initialize(technique)
super(technique)
end
end

Wrestler.rb:
require 'Fighter'
class Wrestler < Fighter
def initialize(technique)
super(technique)
end
end

RoundhouseKick.rb:
require 'MethodMissing'
class RoundhouseKick
include MethodMissing
def execute
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
require 'MethodMissing'
class ShootIn
include MethodMissing
def execute
puts "Shoot In!"
end
end

LegSweep.rb:
require 'MethodMissing'
class LegSweep
include MethodMissing
def execute
puts "Leg Sweep!"
end
end

Jab.rb:
require 'MethodMissing'
class Jab
include MethodMissing
def execute
puts "Jab!"
end
end

Fight.rb:
# Create two fighters assigning initial attack types
rounds = 3
fighters = [ JudoPlayer.new(LegSweep.new), KickBoxer.new(RoundhouseKick.new) ]
# Fight three rounds
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# now swap in new behaviors
fighters[0].attack = ShootIn.new
fighters[1].attack = Jab.new
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). Once the framework of the design is in place, there are many features of the Ruby language that could be used to make the implementation more succinct than than the Java version.

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, Ruby does offer a means to further simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-02T01:21:54Z

Kctreima: /* Comparison of Implementations */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes, behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from the object being acted upon.

===Generic Strategy Class Diagram===
[[Image:Strategy Class Diagram.jpg|Strategy Class Diagram]]

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [http://www.refactoring.com/ Refactoring]) are described where the strategy design pattern could be used to architect a better solution. These include:
<ol>
<li> A class that exhibits many behaviors</li>
<li> A class that uses many variations of an algorithm</li>
<li> A class that uses data structures related to a behavior but not the class</li>
<li> Many similar classes that differ only in a type of behavior</li>
</ol>

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
<ol>
<li> Allows classes to change behavior at runtime or design time</li>
<li> Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]</li>
<li> Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]</li>
<li> A well known design pattern communicates the intent of the code more readily</li>
</ol>

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(technique)
@attack = technique
end
def fight
@attack.execute
end
end

MethodMissing.rb
module MissingMethod
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
class JudoPlayer < Fighter
def initialize(technique)
super(technique)
end
end

KickBoxer.rb:
require 'Fighter'
class KickBoxer < Fighter
def initialize(technique)
super(technique)
end
end

Boxer.rb:
require 'Fighter'
class Boxer < Fighter
def initialize(technique)
super(jab)
end
end

Wrestler.rb:
require 'Fighter'
class Wrestler < Fighter
def initialize(technique)
super(shoot_in)
end
end

RoundhouseKick.rb:
require 'MethodMissing'
class RoundhouseKick
include MethodMissing
def execute
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
require 'MethodMissing'
class ShootIn
include MethodMissing
def execute
puts "Shoot In!"
end
end

LegSweep.rb:
require 'MethodMissing'
class LegSweep
include MethodMissing
def execute
puts "Leg Sweep!"
end
end

Jab.rb:
require 'MethodMissing'
class Jab
include MethodMissing
def execute
puts "Jab!"
end
end

Fight.rb:
# Create two fighters assigning initial attack types
rounds = 3
fighters = [ JudoPlayer.new(LegSweep.new), KickBoxer.new(RoundhouseKick.new) ]
# Fight three rounds
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end
# now swap in new behaviors
fighters[0].attack = ShootIn.new
fighters[1].attack = Jab.new
fighters.each do |fighter|
fighter.fight
end

==Comparison of Implementations==

===Clarity===
Both languages can do the basic implementation of the design pattern framework with near equal clarity. The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). Once the framework of the design is in place, there are many features of the Ruby language that could be used to make the implementation more succinct than than the Java version.

===Succinctness===
Overall, the two implementations are fairly similar in their succinctness, but in general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains fewer lines of code than the Java implementation. If you ignore packaging (Java package statements) though, there are actually more lines in the Ruby implementation. However, Ruby does offer a means to further simplify the code by using its block construct and Proc objects. This will work for simple strategy patterns and could allow for the elimination of the behavioral classes altogether. To make a comparison with Java, the Java strategy pattern would need to be implemented using anonymous inner classes, in which case Ruby's more versatile block construct would be easier to implement and maintain.

The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. The block idiom in Ruby would allow new attack behaviors to be created on the fly at run time in addition to being assigned at compile time. This meta-programming capability allows flexibility that Java does not support. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

===Concluding Remarks===
It would be nice to be able to say that one implementation was always clearer or more succinct than the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity. Choosing a design implementation may come down to familiarity with the language or design decisions outside the scope of this discussion.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T06:49:51Z

Kctreima: /* Java */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from object being acted upon.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [[==References==|Refactoring]]) are described where the strategy design pattern could be used to architect a better solution. These include:
1. A class that exhibits many behaviors
2. A class that uses many variations of an algorithm
3. A class that uses data structures related to a behavior but not the class
4. Many similar classes that differ only in a type of behavior

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
1. Allows classes to change behavior at runtime or design time
2. Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
3. Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
4. A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
rounds = 3
fighters = [ Boxer.new, Wrestler.new ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end

==Comparison of Implementations==
It would be nice to be able to say that one implementation was always clearer or more succinct that the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity.

===Clarity===
The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
In general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains 10 fewer lines of code than the Java implementation (13 fewer if you don't count the method_missing method added to Fighter that is called if you ask him to execute an attack he hasn't learned). However, if you ignore packaging (Java package statements), the difference is much less. Considering that, since Ruby does not need Interfaces there is one less file in the Ruby implementation, there is hardly any difference at all. The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. In Ruby, you can create a new attack simply by passing a Proc object to the Fighter's attack= method at run time. That object can be either a method from a new Module, or created on the fly using Proc.new followed by a block. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T06:24:10Z

Kctreima: /* Strategy Pattern Implementation in Java and Ruby */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from object being acted upon.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [[==References==|Refactoring]]) are described where the strategy design pattern could be used to architect a better solution. These include:
1. A class that exhibits many behaviors
2. A class that uses many variations of an algorithm
3. A class that uses data structures related to a behavior but not the class
4. Many similar classes that differ only in a type of behavior

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
1. Allows classes to change behavior at runtime or design time
2. Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
3. Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
4. A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack. To see our Fighters in action, there is also a Fight class in Java, and a Fight script which can be run in Ruby.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}

}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
rounds = 3
fighters = [ Boxer.new, Wrestler.new ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end

==Comparison of Implementations==
It would be nice to be able to say that one implementation was always clearer or more succinct that the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity.

===Clarity===
The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
In general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains 10 fewer lines of code than the Java implementation (13 fewer if you don't count the method_missing method added to Fighter that is called if you ask him to execute an attack he hasn't learned). However, if you ignore packaging (Java package statements), the difference is much less. Considering that, since Ruby does not need Interfaces there is one less file in the Ruby implementation, there is hardly any difference at all. The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. In Ruby, you can create a new attack simply by passing a Proc object to the Fighter's attack= method at run time. That object can be either a method from a new Module, or created on the fly using Proc.new followed by a block. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T06:20:54Z

Kctreima: /* Java */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from object being acted upon.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [[==References==|Refactoring]]) are described where the strategy design pattern could be used to architect a better solution. These include:
1. A class that exhibits many behaviors
2. A class that uses many variations of an algorithm
3. A class that uses data structures related to a behavior but not the class
4. Many similar classes that differ only in a type of behavior

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
1. Allows classes to change behavior at runtime or design time
2. Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
3. Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
4. A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter[] fighters = { new Boxer(), new Wrestler() };
for (int round = 0; round < 3; round++) {
for (int fighter = 0; fighter < fighters.length; fighter++) {
fighters[fighter].fight();
}
}

}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
rounds = 3
fighters = [ Boxer.new, Wrestler.new ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end

==Comparison of Implementations==
It would be nice to be able to say that one implementation was always clearer or more succinct that the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity.

===Clarity===
The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
In general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains 10 fewer lines of code than the Java implementation (13 fewer if you don't count the method_missing method added to Fighter that is called if you ask him to execute an attack he hasn't learned). However, if you ignore packaging (Java package statements), the difference is much less. Considering that, since Ruby does not need Interfaces there is one less file in the Ruby implementation, there is hardly any difference at all. The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. In Ruby, you can create a new attack simply by passing a Proc object to the Fighter's attack= method at run time. That object can be either a method from a new Module, or created on the fly using Proc.new followed by a block. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T06:08:17Z

Kctreima: /* References */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from object being acted upon.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [[==References==|Refactoring]]) are described where the strategy design pattern could be used to architect a better solution. These include:
1. A class that exhibits many behaviors
2. A class that uses many variations of an algorithm
3. A class that uses data structures related to a behavior but not the class
4. Many similar classes that differ only in a type of behavior

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
1. Allows classes to change behavior at runtime or design time
2. Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
3. Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
4. A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter f1 = new Boxer();
Fighter f2 = new Wrestler();
for (int round = 0; round < 3; round++) {
f1.fight();
f2.fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
rounds = 3
fighters = [ Boxer.new, Wrestler.new ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end

==Comparison of Implementations==
It would be nice to be able to say that one implementation was always clearer or more succinct that the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity.

===Clarity===
The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
In general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains 10 fewer lines of code than the Java implementation (13 fewer if you don't count the method_missing method added to Fighter that is called if you ask him to execute an attack he hasn't learned). However, if you ignore packaging (Java package statements), the difference is much less. Considering that, since Ruby does not need Interfaces there is one less file in the Ruby implementation, there is hardly any difference at all. The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. In Ruby, you can create a new attack simply by passing a Proc object to the Fighter's attack= method at run time. That object can be either a method from a new Module, or created on the fly using Proc.new followed by a block. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
Head First Design Patterns, Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates, O'Reilly Media, 2004
Programming Ruby, Dave Thomas with Chad Fowler and Andy Hunt, The Pragmatic Programmers, 2005
CSC/ECE517 Lecture Notes (lecture 10), Edward F. Gehringer, 2007
[http://en.wikipedia.org/wiki/Strategy_pattern Strategy Pattern - Wikipedia]
[http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=9&t=003846 Command vs Strategy Pattern? (OO, Patterns, UML and Refactoring forum at JavaRanch)]
[http://www.rubynoob.com/articles/2006/5/16/strategy-design-pattern-in-ruby Rubynoob Strategy Design Pattern in Ruby]
[http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/151744 Re: Head First Design Patterns - Strategy Pattern [was: Java/C# "interface" in Ruby ?]]

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T05:48:06Z

Kctreima: /* Comparison of Implementations */

==Introduction==

===What is the Strategy Pattern?===
The strategy pattern is a proven object oriented design pattern that can be used to solve a common coupling problem often found in software development. Often during the development of compositional classes behaviors and algorithms can become mixed into the class during development without realizing that these behaviors or algorithms may change, become more complex, or additional behaviors may need to be added. These changes could be implemented by extending the class's behavior through inheritance, but over time this could result in an overly complex class hierarchy. The strategy pattern is a design template that can be used to decouple the behavior and algorithms from object being acted upon.

===When to Use the Strategy Pattern===
In the seminal book on design patterns by the Gang-of-Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides), situations (also labeled "code smells" by Martin Fowler in [[==References==|Refactoring]]) are described where the strategy design pattern could be used to architect a better solution. These include:
1. A class that exhibits many behaviors
2. A class that uses many variations of an algorithm
3. A class that uses data structures related to a behavior but not the class
4. Many similar classes that differ only in a type of behavior

===Advantages of the Strategy Pattern===
By decoupling through the use of composition rather than inheritance, several advantages emerge that improve the maintainability and readability of the code.
1. Allows classes to change behavior at runtime or design time
2. Decreases code duplication among classes using variations of the same behavior [http://en.wikipedia.org/wiki/Strategy_pattern]
3. Behavior is better encapsulated by not being buried in its context [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/StrategyPattern.htm]
4. A well known design pattern communicates the intent of the code more readily

===Similar Patterns===
[http://en.wikipedia.org/wiki/State_pattern State], [http://www.exciton.cs.rice.edu/JAvaResources/DesignPatterns/command.htm Command], and [http://en.wikipedia.org/wiki/Bridge_pattern Bridge]
Use the state pattern when the state of the object changes with a change in behavior.
Use the bridge pattern when a structural design is needed.
For a discussion of the strategy pattern compared to the state and bridge patterns see [http://lists.cs.uiuc.edu/pipermail/gang-of-4-patterns/2003-November/000064.html Strategy Pattern vs. Bridge Pattern].
Use the command pattern when the invoking object (the context object in the state pattern) does not have knowlege of the recipient object (the behavior in the state pattern). The intermediary command object takes care of dispatching the request to the appropriate object.

==Strategy Pattern Implementation in Java and Ruby==
For our example, we chose to model a video game where there could be different types of Fighters pitted against each other, as you might see in the [http://en.wikipedia.org/wiki/UFC UFC]. In our case, the strategy is the Attack. Each Fighter has a different type of Attack according to his training. The Fighter is therefore an "abstract" class. In statically-typed Java, the class itself is declared as abstract, and in dynamic Ruby it must be extended (or else the Fighter will not know any techniques). To keep things simple, our fighters are not very smart or well-trained, so they each only get one Attack.

===Class Diagram===
[[Image:Wiki1bClasses.jpg|Strategy pattern class diagram]]

===Java===
Fighter.java:
package csc517.wiki1b;
public abstract class Fighter {
private Attack attack;
public Fighter(){
setAttack();
}
public Attack getAttack() {
return attack;
}
public void setAttack(Attack attack) {
this.attack = attack;
}
protected abstract void setAttack();
public void fight() {
getAttack().execute();
}
}

JudoPlayer.java:
package csc517.wiki1b;
public class JudoPlayer extends Fighter {
public void setAttack() {
setAttack(new LegSweep());
}
}

KickBoxer.java:
package csc517.wiki1b;
public class KickBoxer extends Fighter {
public void setAttack() {
setAttack(new RoundhouseKick());
}
}

Boxer.java:
package csc517.wiki1b;
public class Boxer extends Fighter {
public void setAttack() {
setAttack(new Jab());
}
}

Wrestler.java:
package csc517.wiki1b;
public class Wrestler extends Fighter {
public void setAttack() {
setAttack(new ShootIn());
}
}

Attack.java:
package csc517.wiki1b;
public interface Attack {
public void execute();
}

RoundhouseKick.java:
package csc517.wiki1b;
public class RoundhouseKick implements Attack {
public void execute() {
System.out.println("Roundhouse Kick!");
}
}

ShootIn.java:
package csc517.wiki1b;
public class ShootIn implements Attack {
public void execute() {
System.out.println("Shoot In!");
}
}

LegSweep.java:
package csc517.wiki1b;
public class LegSweep implements Attack {
public void execute() {
System.out.println("Leg Sweep!");
}
}

Jab.java:
package csc517.wiki1b;
public class Jab implements Attack {
public void execute() {
System.out.println("Jab!");
}
}

Fight.java:
package csc517.wiki1b;
public class Fight {
public static void main(String[] args) {
Fighter f1 = new Boxer();
Fighter f2 = new Wrestler();
for (int round = 0; round < 3; round++) {
f1.fight();
f2.fight();
}
}
}

===Ruby===
Fighter.rb:
class Fighter
attr_accessor :attack
def initialize(&technique)
@attack = technique
end
def fight
@attack.call
end
def method_missing(method_name)
puts "I don't know how to #{method_name}"
end
end

JudoPlayer.rb:
require 'Fighter'
require 'LegSweep'
class JudoPlayer < Fighter
include LegSweep
def initialize
super { leg_sweep }
end
end

KickBoxer.rb:
require 'Fighter'
require 'RoundhouseKick'
class KickBoxer < Fighter
include RoundhouseKick
def initialize
super { roundhouse_kick }
end
end

Boxer.rb:
require 'Fighter'
require 'Jab'
class Boxer < Fighter
include Jab
def initialize
super { jab }
end
end

Wrestler.rb:
require 'Fighter'
require 'ShootIn'
class Wrestler < Fighter
include ShootIn
def initialize
super { shoot_in }
end
end

RoundhouseKick.rb:
module RoundhouseKick
def roundhouse_kick
puts "Roundhouse Kick!"
end
end

ShootIn.rb:
module ShootIn
def shoot_in
puts "Shoot In!"
end
end

LegSweep.rb:
module LegSweep
def leg_sweep
puts "Leg Sweep!"
end
end

Jab.rb:
module Jab
def jab
puts "Jab!"
end
end

Fight.rb:
require 'Boxer'
require 'Wrestler'
require 'KickBoxer'
require 'JudoPlayer'
rounds = 3
fighters = [ Boxer.new, Wrestler.new ]
rounds.times do
fighters.each do |fighter|
fighter.fight
end
end

==Comparison of Implementations==
It would be nice to be able to say that one implementation was always clearer or more succinct that the other, but as with most things, it is a compromise. To get a little more clarity in Java, you sacrifice some succinctness, and in Ruby you can get more succinctness for the price of some clarity.

===Clarity===
The Java implementation relies less on language idioms, making it somewhat more clear (but not always). For example, to anyone familiar with O-O languages (but not necessarily Java), it is clear what each of the concrete Fighter types does, as well as the Attacks. However, the abstract Fighter class might not be as obvious (but probably still should be). In Ruby, the strategy is implemented as a Proc object, so code to "call" an attack may not be as self-commenting as to execute an Attack. Also, it is obvious that setAttack(new LegSweep()) sets the attack to be a leg sweep, but the call to super { leg_sweep } may not be.

===Succinctness===
In general, the Ruby implementation is more concise. Ruby's built-in iterators make it easier to work with collections, like arrays of Fighters, or rounds in a Fight. Also, the Ruby version contains 10 fewer lines of code than the Java implementation (13 fewer if you don't count the method_missing method added to Fighter that is called if you ask him to execute an attack he hasn't learned). However, if you ignore packaging (Java package statements), the difference is much less. Considering that, since Ruby does not need Interfaces there is one less file in the Ruby implementation, there is hardly any difference at all. The real advantage to using Ruby becomes more apparent when you extend the design to model more real-world situations. Then you can take advantage of its dynamic nature. For example, let's consider when a Fighter wants to learn new techniques, and be able to choose which one to use. In Java, you need to create new Attack implementations before you can use them in a Fight. Then you need to create a mechanism to choose which attack to use. In Ruby, you can create a new attack simply by passing a Proc object to the Fighter's attack= method at run time. That object can be either a method from a new Module, or created on the fly using Proc.new followed by a block. Also, if you wanted to combine several attacks into an arsenal from which the fighter could choose any attack, this could be easily accomplished using Ruby's arrays and built-in iterators.

==References==

Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Pulishing, 1995
Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley Publishing, 1999
http://en.wikipedia.org/wiki/Strategy_pattern

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T04:20:34Z

Kctreima: /* Strategy Pattern Implementation in Java and Ruby */

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T04:01:00Z

Kctreima: /* Class Diagram */

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T03:57:09Z

Kctreima: /* Strategy Pattern Implementation in Java and Ruby */

File:Wiki1bClasses.jpg

2007-10-01T03:55:43Z

Kctreima: The class diagram shows the strategy (Attack), different implementations of the strategy (RoundhouseKick, Jab, etc.), an abstract user of the strategy (Fighter), and different concrete extensions (Boxer, Wrestler, etc.).

The class diagram shows the strategy (Attack), different implementations of the strategy (RoundhouseKick, Jab, etc.), an abstract user of the strategy (Fighter), and different concrete extensions (Boxer, Wrestler, etc.).

CSC/ECE 517 Fall 2007/wiki1b 8 ktrk

2007-10-01T03:48:28Z

Kctreima: /* Strategy Pattern Implementation in Java and Ruby */