Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T03:53:32Z

Sbselvad: /* Bob Martin */

'''Topic'''

O-o design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

* Reuse/Release Equivalency principle,
* Common Closure principle,
* Common Reuse principle,
* Acyclic Dependencies principle,
* Stable Dependencies principle, and
* Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

= Design principles related to Packages =

Object Oriented Programming (OOP) is a methodology for modelling and designing software systems which encompasses the basic concepts of encapsulation, abstraction, inheritance and polymorphism. This methodology is guided by a set of principles, called the Design Principles. These principles show the right direction of designing and helps in avoiding costly mistakes at the designing stage. The design principles are not important only from a software design point of view, but also from a business because design principles enable flexible designs, which can evolve with the business requirements with minimum effort, time and cost.

There are Class Desgin principles and Package Design principles, here we will discuss on the Package Design principles alone.

== Bob Martin ==

[http://www.objectmentor.com/omTeam/martin_r.html Robert C. Martin] has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report.

= Reuse/Release Equivalency Principle (REP)=

The Reuse/Release Equivalency Principle (REP) states that

<code>The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.</code>

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

== Example ==

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

= Common Closure Principle (CCP) =

The Common Closure Principle (CCP) states that

<code>The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.</code>

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

== Example ==

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.

= Common Reuse Principle (CRP) =

The Common Reuse Principle (CRP) states that,

<code>The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.</code>

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

== Example ==
For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

= Acyclic Dependencies Principle (ADP) =

The Acyclic Dependency Priniciple (ADP) states that

<code>The dependency structure between packages must be a Directed Acyclic Graph (DAG).</code>

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

== Example ==

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.

= Stable Dependencies Principle (SDP) =

The Stable Dependencies Principle (SDP) states that

<code>The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.</code>

According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.

Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.

== Example ==

An interface called <code>Logger</code> will be more stable than classes <code>FileLogger</code> or <code>DBLogger</code>

= Stable Abstraction Principle (SAP) =

Stable Abstraction Principle (SAP) states that

<code>Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.</code>

Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means, that dependencies in packages are in the direction of abstraction.

== Example ==

Lets try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.

= References =

=== Books ===

# [http://www.amazon.com/Designing-Object-Oriented-Applications-Method/dp/0132038374 Designing Object-Oriented C++ Applications using the Booch Method]
# [http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445 Agile Software Development: Principles, Patterns and Practices]

=== Links ===

# [http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf Principles of Object-oriented design]
# [http://staff.cs.utu.fi/kurssit/Programming-III/PackageDesing.pdf Presentation on package design principles]
# [http://tdoks.blogspot.com/2007/02/principles-of-software-development.html Principles of Software Development]

=== See Also ===
# [http://www.java-entrepreneur.com/50226711/design_patterns_versus_design_principles.php Design Patterns Vs Design Principles]
# [http://www.artima.com/forums/flat.jsp?forum=276&thread=134747 Discussion on Design Patterns Vs Design Principles]
# [http://www.xp.co.nz/Coding_Standards_for_Java.htm Exteme programming and Design Principles]

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T03:52:35Z

Sbselvad: /* References */

'''Topic'''

O-o design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

* Reuse/Release Equivalency principle,
* Common Closure principle,
* Common Reuse principle,
* Acyclic Dependencies principle,
* Stable Dependencies principle, and
* Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

= Design principles related to Packages =

Object Oriented Programming (OOP) is a methodology for modelling and designing software systems which encompasses the basic concepts of encapsulation, abstraction, inheritance and polymorphism. This methodology is guided by a set of principles, called the Design Principles. These principles show the right direction of designing and helps in avoiding costly mistakes at the designing stage. The design principles are not important only from a software design point of view, but also from a business because design principles enable flexible designs, which can evolve with the business requirements with minimum effort, time and cost.

There are Class Desgin principles and Package Design principles, here we will discuss on the Package Design principles alone.

== Bob Martin ==

Robert C. Martin has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report.

= Reuse/Release Equivalency Principle (REP)=

The Reuse/Release Equivalency Principle (REP) states that

<code>The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.</code>

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

== Example ==

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

= Common Closure Principle (CCP) =

The Common Closure Principle (CCP) states that

<code>The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.</code>

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

== Example ==

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.

= Common Reuse Principle (CRP) =

The Common Reuse Principle (CRP) states that,

<code>The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.</code>

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

== Example ==
For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

= Acyclic Dependencies Principle (ADP) =

The Acyclic Dependency Priniciple (ADP) states that

<code>The dependency structure between packages must be a Directed Acyclic Graph (DAG).</code>

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

== Example ==

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.

= Stable Dependencies Principle (SDP) =

The Stable Dependencies Principle (SDP) states that

<code>The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.</code>

According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.

Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.

== Example ==

An interface called <code>Logger</code> will be more stable than classes <code>FileLogger</code> or <code>DBLogger</code>

= Stable Abstraction Principle (SAP) =

Stable Abstraction Principle (SAP) states that

<code>Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.</code>

Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means, that dependencies in packages are in the direction of abstraction.

== Example ==

Lets try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.

= References =

=== Books ===

# [http://www.amazon.com/Designing-Object-Oriented-Applications-Method/dp/0132038374 Designing Object-Oriented C++ Applications using the Booch Method]
# [http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445 Agile Software Development: Principles, Patterns and Practices]

=== Links ===

# [http://labs.cs.utt.ro/labs/acs/html/lectures/6/lecture6.pdf Principles of Object-oriented design]
# [http://staff.cs.utu.fi/kurssit/Programming-III/PackageDesing.pdf Presentation on package design principles]
# [http://tdoks.blogspot.com/2007/02/principles-of-software-development.html Principles of Software Development]

=== See Also ===
# [http://www.java-entrepreneur.com/50226711/design_patterns_versus_design_principles.php Design Patterns Vs Design Principles]
# [http://www.artima.com/forums/flat.jsp?forum=276&thread=134747 Discussion on Design Patterns Vs Design Principles]
# [http://www.xp.co.nz/Coding_Standards_for_Java.htm Exteme programming and Design Principles]

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:28:18Z

Sbselvad: /* Design principles related to Packages */

'''Topic'''

O-o design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

* Reuse/Release Equivalency principle,
* Common Closure principle,
* Common Reuse principle,
* Acyclic Dependencies principle,
* Stable Dependencies principle, and
* Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

= Design principles related to Packages =

Object Oriented Programming (OOP) is a methodology for modelling and designing software systems which encompasses the basic concepts of encapsulation, abstraction, inheritance and polymorphism. This methodology is guided by a set of principles, called the Design Principles. These principles show the right direction of designing and helps in avoiding costly mistakes at the designing stage. The design principles are not important only from a software design point of view, but also from a business because design principles enable flexible designs, which can evolve with the business requirements with minimum effort, time and cost.

There are Class Desgin principles and Package Design principles, here we will discuss on the Package Design principles alone.

== Bob Martin ==

Robert C. Martin has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report.

= Reuse/Release Equivalency Principle (REP)=

The Reuse/Release Equivalency Principle (REP) states that

<code>The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.</code>

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

== Example ==

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

= Common Closure Principle (CCP) =

The Common Closure Principle (CCP) states that

<code>The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.</code>

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

== Example ==

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.

= Common Reuse Principle (CRP) =

The Common Reuse Principle (CRP) states that,

<code>The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.</code>

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

== Example ==
For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

= Acyclic Dependencies Principle (ADP) =

The Acyclic Dependency Priniciple (ADP) states that

<code>The dependency structure between packages must be a Directed Acyclic Graph (DAG).</code>

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

== Example ==

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.

= Stable Dependencies Principle (SDP) =

The Stable Dependencies Principle (SDP) states that

<code>The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.</code>

According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.

Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.

== Example ==

An interface called <code>Logger</code> will be more stable than classes <code>FileLogger</code> or <code>DBLogger</code>

= Stable Abstraction Principle (SAP) =

Stable Abstraction Principle (SAP) states that

<code>Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.</code>

Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means, that dependencies in packages are in the direction of abstraction.

== Example ==

Lets try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.

= References =

== Books ==

== Links ==

== See Also ==

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:25:39Z

Sbselvad: /* Bob Martin */

'''Topic'''

O-o design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

* Reuse/Release Equivalency principle,
* Common Closure principle,
* Common Reuse principle,
* Acyclic Dependencies principle,
* Stable Dependencies principle, and
* Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

= Design principles related to Packages =

== Bob Martin ==

Robert C. Martin has been a software professional since 1970. In the last 35 years, he has worked in various capacities on literally hundreds of software projects. He has authored "landmark" books on Agile Programming, Extreme Programming, UML, Object-Oriented Programming, and C++ Programming. He has published dozens of articles in various trade journals. Today, He is one of the software industry's leading authorities on Agile software development and is a regular speaker at international conferences and trade shows. He is a former editor of the C++ Report and currently writes a monthly Craftsman column for Software Development magazine.

= Reuse/Release Equivalency Principle (REP)=

The Reuse/Release Equivalency Principle (REP) states that

<code>The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.</code>

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

== Example ==

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

= Common Closure Principle (CCP) =

The Common Closure Principle (CCP) states that

<code>The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.</code>

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

== Example ==

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.

= Common Reuse Principle (CRP) =

The Common Reuse Principle (CRP) states that,

<code>The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.</code>

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

== Example ==
For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

= Acyclic Dependencies Principle (ADP) =

The Acyclic Dependency Priniciple (ADP) states that

<code>The dependency structure between packages must be a Directed Acyclic Graph (DAG).</code>

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

== Example ==

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.

= Stable Dependencies Principle (SDP) =

The Stable Dependencies Principle (SDP) states that

<code>The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.</code>

According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.

Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.

== Example ==

An interface called <code>Logger</code> will be more stable than classes <code>FileLogger</code> or <code>DBLogger</code>

= Stable Abstraction Principle (SAP) =

Stable Abstraction Principle (SAP) states that

<code>Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.</code>

Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means, that dependencies in packages are in the direction of abstraction.

== Example ==

Lets try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.

= References =

== Books ==

== Links ==

== See Also ==

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:21:14Z

Sbselvad: /* Stable Abstraction principle */

'''Topic'''

O-o design guru Bob Martin has developed a set of design principles that relate to packages (one level above the class-oriented strategies we consider in this course). Report on the

* Reuse/Release Equivalency principle,
* Common Closure principle,
* Common Reuse principle,
* Acyclic Dependencies principle,
* Stable Dependencies principle, and
* Stable Abstraction principle

Find the best descriptions and examples of each that you can find on the Web.

= Design principles related to Packages =

== Bob Martin ==

= Reuse/Release Equivalency Principle (REP)=

The Reuse/Release Equivalency Principle (REP) states that

<code>The granule of reuse is the granule of release. Only components that are released through a tracking system can be effectively reused. This granule is the package.</code>

According to this, package is to be considered as the unit of distribution of software. When one wants to reuse components, package has to be the concrete unit that should be reused. The term package may also be interpreted as library, domain, functionality or a set of classes bound together.

An interesting argument can be that, why not use classes as the unit of distribution? The reason is that quiet often by design, we end up with more than one class that communicate with each other. If individual classes are released, tracking version and compatibility can become very difficult. Hence, packages which are in the level next to classes, are the granular units of release and therfore reused even if classes can be the units of design.

The tracking system is important because the author owns the responsibility of upgrading the package that is being reused. Changes or enhancements in the package can be triggered by many factors, like new standards, new requirements, bugs or sometimes new methodologies and technologies. The author has to track the changes in the package along with maintaining its source code.

== Example ==

Lets say one wants use a file operations library. The library itself is the unit of distribution and usage (referred to as the package), even if we use only one particular class for reading a file.

= Common Closure Principle (CCP) =

The Common Closure Principle (CCP) states that

<code>The classes in a package should be closed together against the same kind of changes. A change that affects a package affects all the classes in that package.</code>

This principle focuses at maintainability rather than usability. The principle guides on which classes should be packaged together from a change and distribution point of view. Though most of the class design principles advocate loose coupling between classes, so that they can change without affecting the other, dependencies between classes is inevitable. This principle tries to look at classes that are dependent on each other from a code change perspective. Even though Open-Closed Principle (OCP) recomments full closure to code change, it is not always possible. However this violation should be a conscious decision and the product should be ready for changes because of it.

To enable easy distribution/update/release and maintainability, it is advisable to localise the changes to a package. Only the modified package can then be released, making the update easier. Even if the changes cannot be restricted to a single package, minimal packages should be required to be changed. To get an idea of the code change dependencies, we can take guidance from Law Of Demeter (LOD) principle, which tries to point out classes which know each other’s structures.

== Example ==

A good example for application of CCP is a package modeled after a relational database. Class designs might need to be consciously violated during denormalization of the database model for performance improvements. During this time changes to the package affects all classes in that package.

= Common Reuse Principle (CRP) =

The Common Reuse Principle (CRP) states that,

<code>The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.</code>

This principle stresses on the importance of a package (a set of cohesive classes) to be used for releasing reusable software, and the importance of releasing software that can be tracked, so that the users get a guarantee of interface and behaviour from the author.However, it is very important to decide which classes should be bound together by a package. Improper selection of classes can create unwanted dependencies and complicate usage of that package. Common Reuse Principle (CRP) lays down the foundations to determine which classes should be packaged together.

According to this principle, only cohesive classes should be packaged together. The packaging of classes and the cohesiveness should be defined from the user’s perspective. If a user uses a package, all the classes in that package should be reusable in the same context. A rule that can be a derivative of this is that all the classes related to a functionality should be packaged together. For example,

As specified by Reuse/Release Equivalency Principle (REP), even if one or two classes are being used, the granularity to be considered is the entire package. This dependency means that with every revision or release of that package, the software has to be tested and revalidated, irrespective of whether the modified class is being used or not. Hence, only those classes should be packaged together which will be reused together.

== Example ==
For a matrix calculations pakage, it better have only those classes related to matrices and not trigonometric functions.

= Acyclic Dependencies Principle (ADP) =

The Acyclic Dependency Priniciple (ADP) states that

<code>The dependency structure between packages must be a Directed Acyclic Graph (DAG).</code>

This principle is important from a deployment perspective. A package apart from being reusable and maintanable, should also be deployable. The package design should have defined dependencies so that it is deployment-friendly.

DAG implies that in the package dependency traversal, there should be no path which includes the same package more than once. DAG leads to a clear dependency structure, which can instantly identify the packages that can get affected if a certain package is modified. Cyclic dependencies usually happen when multiple developers work on the same package, on the same module or on the same class. These cyclick dependencies can be broken. One of the methods is to use Dependency Inversion Principle (DIP).The dependency graphs lead directly to the map for building the packages and the entire application. Considering this at the early stages of package design saves lot of time and effort.

== Example ==

The simplest cyclic dependency means that a package A depends on package B, which again depends on package A. Not only does this lead to wrong class dependencies, but also makes deployment a difficult and unmaintainable.

= Stable Dependencies Principle (SDP) =

The Stable Dependencies Principle (SDP) states that

<code>The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.</code>

According to this principle, a package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP). Why do we need to look at stability point of view? We need to do this as we define a dependency chain, which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes.

Quiet often, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.It is important to identify stable packages and unstable packages. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.

== Example ==

An interface called <code>Logger</code> will be more stable than classes <code>FileLogger</code> or <code>DBLogger</code>

= Stable Abstraction Principle (SAP) =

Stable Abstraction Principle (SAP) states that

<code>Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.</code>

Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. Applying Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the concrete classes. This ultimately means, that dependencies in packages are in the direction of abstraction.

== Example ==

Lets try to explain this by discussion. An abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.

= References =

== Books ==

== Links ==

== See Also ==

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:11:41Z

Sbselvad: /* Stable Dependencies principle */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:02:12Z

Sbselvad: /* Reuse/Release Equivalency Principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T02:01:36Z

Sbselvad: /* Reuse/Release Equivalency Principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:59:31Z

Sbselvad: /* Acyclic Dependencies principle */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:49:28Z

Sbselvad: /* Common Reuse principle (CRP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:49:17Z

Sbselvad: /* Common Closure principle (CCP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:49:02Z

Sbselvad: /* Reuse/Release Equivalency principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:48:48Z

Sbselvad: /* Common Reuse principle */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:40:39Z

Sbselvad: /* Common Closure principle */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:24:03Z

Sbselvad: /* Reuse/Release Equivalency principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:22:32Z

Sbselvad: /* Reuse/Release Equivalency principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:20:48Z

Sbselvad: /* Reuse/Release Equivalency principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:20:31Z

Sbselvad: /* Reuse/Release Equivalency principle (REP) */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:20:02Z

Sbselvad: /* Reuse/Release Equivalency principle */

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-20T01:08:10Z

Sbselvad:

CSC/ECE 517 Fall 2007/wiki3 8 ss

2007-11-18T02:36:44Z

Sbselvad:

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:50:08Z

Sbselvad: /* Strategy Pattern */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of [http://en.wikipedia.org/wiki/Algorithm algorithms], encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/[http://en.wikipedia.org/wiki/Mixins mixins] of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:49:56Z

Sbselvad: /* Strategy Pattern */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of [[http://en.wikipedia.org/wiki/Algorithm algorithms], encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/[http://en.wikipedia.org/wiki/Mixins mixins] of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:49:27Z

Sbselvad: /* Merits */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/[http://en.wikipedia.org/wiki/Mixins mixins] of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:48:46Z

Sbselvad: /* Where Ruby wins? */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of [http://en.wikipedia.org/wiki/Algorithm algorithms] can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/[http://en.wikipedia.org/wiki/Mixins mixins] of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:48:09Z

Sbselvad: /* Comparison */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of [http://en.wikipedia.org/wiki/Algorithm algorithms] can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism]/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:47:02Z

Sbselvad: /* Comparison */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of [http://en.wikipedia.org/wiki/Algorithm algorithms] can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
[http://en.wikipedia.org/wiki/Meta_programming meta programming]
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic [http://en.wikipedia.org/wiki/Regular_expression regular expression] support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:44:24Z

Sbselvad: /* Merits */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of [http://en.wikipedia.org/wiki/Algorithm algorithms] can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:43:38Z

Sbselvad: /* Structure */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like [http://en.wikipedia.org/wiki/Quicksort QuickSort], [http://en.wikipedia.org/wiki/Merge_sort MergeSort], [http://en.wikipedia.org/wiki/Bubble_sort Bubble Sort] etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:40:31Z

Sbselvad: /* Design Patterns */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in [http://en.wikipedia.org/wiki/Object-oriented Object-oriented] designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:39:52Z

Sbselvad: /* Design Patterns */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern] is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:38:55Z

Sbselvad: /* Java's Solution */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the [http://java.sun.com/ Java] implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:37:56Z

Sbselvad: /* Ruby's Solution */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the [http://www.ruby-lang.org/en/ Ruby] implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:34:58Z

Sbselvad: /* Demerits */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

Note: Most of these demerits are specific to statically typed languages like Java. Use of dynamic object oriented languages like Ruby can help bypass these demerits

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T00:29:48Z

Sbselvad: /* Demerits */

= The Strategy Design Pattern, comparing a dynamic OO language to a static OO languaje =

In this page we explore the differences in implementation and design of the Strategy design pattern between the dynamic Object-Oriented language Ruby and the static Object-Oriented language Java.

= Definitions =

== Design Patterns ==

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

== Strategy Pattern ==
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

=== Structure ===

[[Image:Strategy-Example.jpg||Sort using Strategy]]

Normally there are 3 types of classes and or objects that participate in a strategy pattern implementation
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

=== Merits ===

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm are completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

=== Demerits ===

# The application must be aware of all the strategies to select the right one for the right situation.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

=== Related Patterns ===

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

=== Alternatives ===

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Real World Case Study =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object instance containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> object as an instance of a class implementing the <code>FileOperation</code> interface. The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code>. Therefore, <code>FileJob</code> is the context class, the <code>FileOperation</code> interface is the strategy, and <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> are concrete strategies.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T16:16:43Z

Sbselvad:

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

''Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) edited this page.''

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:59:05Z

Sbselvad: /* Where Ruby wins? */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==

The comparison yields interesting insights into the advantages of Ruby over Java. Clearly Ruby has much higher edge in using OO design patterns like strategy over any other statically typed language.

# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:54:22Z

Sbselvad: /* Java versus Ruby */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==
# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Unbounded polymorphism/mixins of Ruby provides better code reusability
# Highly dynamic strategies can be constructed using meta programming features of Ruby
# New algorithms can be evaluated dynamically with ease

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:47:38Z

Sbselvad: /* Comparison */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the
algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using
meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using <code>eval</code>
|-
| Syntactic regular expression support not available.
| Interesting algorithm use cases can be constructed using the
syntactic regular expression support for Ruby
|-
|}

== Where Ruby wins? ==
# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:41:51Z

Sbselvad: /* Comparison */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Algorithms for strategies need to be defined at compile time
| New algorithms for strategies can be created on the fly using meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism/Mixins makes one algorithm reusable
under several strategies
|-
| Difficult to evaluate new algorithms inside strategies
| New algorithms can be evaluated dynamically using eval
|-
|
|
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
|}

== Where Ruby wins? ==
# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:29:15Z

Sbselvad: /* Comparison */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Strategies need to be defined at compile time
| New strategies can be created on the fly using meta programming
|-
| Difficult to include one algorithm under several strategies
| Unbounded polymorphism makes one algorithm reusable under several strategies
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
|}

== Where Ruby wins? ==
# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-01T05:25:18Z

Sbselvad: /* Comparison */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

The Strategy design pattern allows to define a family of algolrithms and makes them interchangeable. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone. The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by a <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
import java.util.ArrayList;

// This is the Strategy interface
interface FileOperation {
public void Run(String from, String to);
}

// These are the three different implementations
class CopyOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Copy " + from + " to " + to + ".");
}
}

class ReencodeOperation implements FileOperation {
private int bitRate_; // In kbps

ReencodeOperation(int bitRate) {
bitRate_ = bitRate;
}

public void Run(String from, String to) {
System.out.println("Reencode " + from + " to " + to + " at " + bitRate_ + "kbps.");
}
}

class RenameOperation implements FileOperation {
public void Run(String from, String to) {
System.out.println("Rename " + from + " to " + to + ".");
}
}

// This is the context class
class FileJob {
String from_;
String to_;
FileOperation op_;

public FileJob(String from, String to, FileOperation op) {
from_ = from;
to_ = to;
op_ = op;
}

void Run() {
op_.Run(from_, to_);
}
}

// Sample code
class Test {
public static void main(String[] args) {
ArrayList<FileJob> jobs = new ArrayList<FileJob>();

FileOperation copyOp = new CopyOperation();
FileOperation renameOp = new RenameOperation();
FileOperation reencodeOp = new ReencodeOperation(128); // kbps

jobs.add(new FileJob("file1", "file2", copyOp));
jobs.add(new FileJob("file3", "file4", renameOp));
jobs.add(new FileJob("file5", "file6", reencodeOp));

for (FileJob j : jobs) {
j.Run();
}
}
}
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
# To give the file operation invocation a better name we define an alias, note
# that this is optional, one can just use 'call', but it is better to adapt
# the name to the problem domain
class FileOperation < Proc
alias_method :run, :call
end

# These are the strategies
copyOp = FileOperation.new { |from, to| puts "Copy #{from} to #{to}." }
renameOp = FileOperation.new { |from, to| puts "Rename #{from} to #{to}." }
bitRate = 128 # kbps
reencodeOp = FileOperation.new { |from, to| puts "Reencode #{from} to #{to} at #{bitRate}kbps." }

# This is the context class
class FileJob
def initialize(from, to, op)
@from = from
@to = to
@op = op
end

def run
@op.run(@from, @to)
end
end

# The same test as the Java implementation
jobs = Array.new

jobs << FileJob.new("file1", "file2", copyOp);
jobs << FileJob.new("file3", "file4", renameOp);
jobs << FileJob.new("file5", "file6", reencodeOp);

jobs.each { |j| j.run() }
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| An interface declaration, defines a common interface to the algorithm family
| No interface declaration required
|-
| A class is required for each strategy implementation
| No classes required, closures are good enough
|-
| Strategies need to be defined at compile time
| New strategies can be created on the fly using metaprogramming
|-
| This is not there
| This is there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
|}

== Where Ruby wins? ==
# Ruby's code is succint, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the stategy implementations, in Java parameters to strategies must be instance or class variables
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:37:59Z

Sbselvad: /* Comparison */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented JAVA code here...
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented RUBY code here...
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation
! Ruby's Strategy Implementation
|-
| This is not there
| This is there
|-
| This is not there
| This is there
|-
| This is not there
| This is there
|-
| This is not there
| This is there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
| This is there
| This is not there
|-
|}

== Where Ruby wins? ==
# Ruby wins 1
# Ruby wins 2
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:28:18Z

Sbselvad:

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented JAVA code here...
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented RUBY code here...
</pre>

= Java versus Ruby =
== Comparison ==
Let us perform a comparison to better understand the implementation

{| border="1" cellspacing="0" cellpadding="5" align="center"
! Java's Strategy Implementation ! Ruby's Strategy Implementation
|- | This is not there | This is there|-|
|- | This is not there| This is there|-|
|- | This is not there| This is there|-|
|- | This is not there| This is there|-|
|- | This is there| This is not there|-|
|- | This is there| This is not there|-|
|- | This is there| This is not there|-|
|- | This is there| This is not there|-|
}

== Where Ruby wins? ==
# Ruby wins 1
# Ruby wins 2
# Ruby wins 3
# Ruby wins 4
# Ruby wins 5
# Ruby wins 6
# Ruby wins 7
# Ruby wins 8

= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

File:Playlist-Example.jpg

2007-09-29T01:21:30Z

Sbselvad:

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:19:39Z

Sbselvad: /* Real World Problem */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

[[Image:Playlist-Example.jpg]]

== Java's Solution ==

Here is the Java implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented JAVA code here...
</pre>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<pre>
Agustin.. Please paste your commented RUBY code here...
</pre>

= Java versus Ruby =
== Comparision ==
== Where Ruby wins? ==
= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:14:23Z

Sbselvad: /* Example & Illustration */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg||Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

== Java's Solution ==

== Ruby's Solution ==

= Java versus Ruby =
== Comparision ==
== Where Ruby wins? ==
= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:10:57Z

Sbselvad: /* Example & Illustration */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg|Sort using Strategy]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

== Java's Solution ==

== Ruby's Solution ==

= Java versus Ruby =
== Comparision ==
== Where Ruby wins? ==
= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:03:31Z

Sbselvad: /* Real World Problem */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths. The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

== Java's Solution ==

== Ruby's Solution ==

= Java versus Ruby =
== Comparision ==
== Where Ruby wins? ==
= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-09-29T01:02:18Z

Sbselvad: /* Real World Problem */

Note: Santthosh (sbselvad@ncsu.edu) and Agustin (agusvega@nc.rr.com) are editing this page.

= Strategy Pattern =

Strategy pattern is one of the several software design patterns, where in algorithms can be selected on-the-fly at runtime execution of the program. The Strategy pattern lets one build software as a loosely coupled collection of interchangeable parts, in contrast to a monolithic, tightly coupled system. That loose coupling makes the software much more extensible, maintainable, and reusable. The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application.

== Concept to explore ==

''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?).''

== Definitions ==

=== Design Patterns ===

A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is neither a finished design nor a solution that can be transformed directly into code. It is a template on how to solve a problem that can be used in many different situations. Design patterns are more often use in Object oriented designs as they typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Note: Algorithms are not design patterns, algorithms solve computational problems and design patterns solve design problems.

=== Strategy Pattern ===
The Strategy Design Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeagle. Stratergy lets the algorithm vary independently from clients that use it.

== Merits ==

# A family of algorithms can be defined as a class hierarchy and can be used interchangeably to alter application behavior without changing its architecture.
# By encapsulating the algorithm separately, new algorithms complying with the same interface can be easily introduced.
# The application can switch strategies at run-time.
# Strategy enables the clients to choose the required algorithm, without using a "switch" statement or a series of "if-else" statements.
# Data structures used for implementing the algorithm is completely encapsulated in Strategy classes. Therefore, the implementation of an algorithm can be changed without affecting the Context class.
# Strategy Pattern can be used instead of sub-classing the Context class. Inheritance hardwires the behavior with the Context and the behavior cannot be changed dynamically.
# The same Strategy object can be strategically shared between different Context objects. However, the shared Strategy object should not maintain states across invocations.

== Demerits ==

# The application must be aware of all the strategies to select the right one for the right situation.
# Strategy and Context classes may be tightly coupled. The Context must supply the relevant data to the Strategy for implementing the algorithm and sometimes, all the data passed by the Context may not be relevant to all the Concrete Strategies.
# Context and the Strategy classes normally communicate through the interface specified by the abstract Strategy base class. Strategy base class must expose interface for all the required behaviors, which some concrete Strategy classes might not implement.
# In most cases, the application configures the Context with the required Strategy object. Therefore, the application needs to create and maintain two objects in place of one.
# Since, the Strategy object is created by the application in most cases; the Context has no control on lifetime of the Strategy object. However, the Context can make a local copy of the Strategy object. But, this increases the memory requirement and has a sure performance impact.

== Related Patterns ==

[http://en.wikipedia.org/wiki/Command_pattern Command] and [http://en.wikipedia.org/wiki/Bridge_Pattern Bridge] are two closely related patterns to Strategy.

* A Command pattern encapsulates a single action, therefore it tends to have a single method with a rather generic signature. It often is intended to be stored for a longer time and to be executed later. Strategy, in contrast, is used to customize an algorithm. A strategy might have a number of methods specific to the algorithm. Most often strategies will be instantiated immediately before executing the algorithm, and discarded afterwards.

* Bridge pattern is meant for structure, whereas the Strategy pattern is meant for behavior. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

== Alternatives ==

In some programming languages, such as those without polymorphism, the issues addressed by strategy pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.

= Example & Illustration =

Normally there are 3 types of classes and or objects that participate in a strategy pattern
* Strategy
: declares an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy

* ConcreteStrategy
: implements the algorithm using the Strategy interface

* Context
: is configured with a ConcreteStrategy object
: maintains a reference to a Strategy object
: may define an interface that lets Strategy access its data.

[[Image:Strategy-Example.jpg]]

For example lets take the general case of sorting a list. One may wish to use different sort strategies based on the length of the list as performance of these sort algorithms vary depending on the size of the list. Here SortStrategy will be the common interface to all supported sort algorithms (like QuickSort, MergeSort, SyncSort etc.,) and SortedList will be the context that lets Strategy access the list and operate on it.

= Real World Problem =

To demonstrate further let us consider an application that manages songs and playlists, and helps you copy/synchronize songs to you compact MP3 player or Mobile phone.The application accepts a playlist which has a catalog of MP3 files in different directories.

Let critical actions performed on the files in playlist be renaming, copying or reencoding. Let each file to be copied/synchronized be represented by <code>FileJob</code> object containing the source and destination paths.

The actual action (rename/copy/reencode) that needs to be performed is given to the <code>FileJob</code> as an object implementing the <code>FileOperation</code> interface (which is the strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (which are the implementations). Here the file under the operations takes the role of context.

== Java's Solution ==

== Ruby's Solution ==

= Java versus Ruby =
== Comparision ==
== Where Ruby wins? ==
= References =

===Books===
#[http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055 Programming Ruby: The programmatic programmer’s guide]
#[http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124 Head First Design Patterns]

===Links===
#[http://www.dofactory.com/Patterns/PatternStrategy.aspx Strategy Pattern - Data and Object Factory]
#[http://en.wikipedia.org/wiki/Design_pattern_(computer_science) Design Patterns - Wikipedia]
#[http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html Strategy for Success - Java World]

===See Also===

#[http://davidhayden.com/blog/dave/archive/2005/07/01/1875.aspx Strategy Design Pattern and Open-Closed Principle]
#[http://www.devshed.com/c/a/PHP/Introducing-the-Strategy-Pattern/ Strategy Pattern for PHP Explained]