Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-28T22:44:26Z

Jvegafr:

''Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.''

= Introduction =
All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behavior. The Interface Segregation Principle (ISP) provides guidelines for designing interfaces to classes that must provide different services to different clients. The Interface Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.

= Definition =

ISP was originally presented in a paper by Robert C. Martin in his ''Engineering Notebook'' column for the ''C++ Report''. The paper is still available at the Object Mentor website [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)].

The essence of Integration Segregation Principle is that
"Clients should not be forced to depend upon interfaces that they don’t use."

Some other definitions of ISP are:
:"Many client specific interfaces are better than one general purpose interface"
:"The dependency of one class to another one should depend on the smallest possible interface"
:"Make fine grained interfaces that are client specific."

While it can be argued that having a class that has many interfaces violates the Single Responsibility Principle [http://www.objectmentor.com/resources/articles/srp.pdf SRP], there are many instances where having a class implementing different interfaces makes sense, e.g., a graphics class might need to be rendered to screen or serialized to a file.

= Examples =

The following two examples are taken from Martin's paper, but have been ported to Java.

== Security system ==

Suppose you have a security system that has Door objects:

<pre>
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};
</pre>

Now suppose you have a TimedDoor which needs to sound an Alarm when the door has been left open for too long. To implement this functionality the TimerDoor object communicates with a Timer object:

<pre>
public class Timer
{
...
public void Register(int timeout, TimerClient* client) {
...
}
...
};

interface TimerClient
{
public void TimeOut();
};
</pre>

We might be tempted to do the following:

<pre>
interface Door extends TimerClient {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door {
...
}
</pre>

The Door interface has been polluted with the Timer interface in order to provide the Timer interface to TimedDoor and all Door clients now also depend on TimerClient. To void this we can do the following instead:

<pre>
// Unchanged from first listing
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door, TimerClient {
...
}
</pre>

This conforms to ISP by providing the required separate interfaces.

== ATM System ==

Consider an ATM that needs to be very flexible and support screen, braille tablet and speech synthesizer user interfaces. We can abstract the main operations and use an interface which would be implemented by specific UI classes:

<pre>
interface ATM_UI {
void deposit(double amt, double account);
void withdraw(double amt, double account);
void transfer(double amt, double fromAccount, double toAccount);
}

public class BrailleUI implements ATM_UI {
...
}

public class ScreenUI implements ATM_UI {
...
}

public class SpeechUI implements ATM_UI {
...
}
</pre>

Now consider also that each different transaction the ATM can perform are encapsulated in a Transaction object:

<pre>
interface Transaction {
void execute();
}

class DepositTransaction implements Transaction {
void execute() {
atm.deposit(amt, acct);
}
}

class WithdrawalTransaction implements Transaction {
void execute() {
atm.withdraw(amt, acct);
}
}

class TransferTransaction implements Transaction {
void execute() {
atm.withdraw(amt, fromAcct, toAcct);
}
}
</pre>

Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface. To fix the problem we can do the following instead:

<pre>
interface DepositUI {
void deposit(double amt, double account);
}

interface WithdrawalUI {
void withdraw(double amt, double account);
}

interface TransferUI {
void transfer(double amt, double fromAccount, double toAccount);
}

interface ATM_UI extends DepositUI, WithdrawalUI, TransferUI {
...
}
</pre>

And have the individual Transaction objects only reference the needed interfaces.

= Web Resources =

We were unable to find many examples of ISP in the web, the reason might be that ISP is very well explained in the original paper [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)], which has two examples in C++ and an early version of UML. These examples use C++'s multiple inheritance due to the lack of real interfaces in the language. Each interface is defined using an abstract class with pure virtual methods. Even when these examples are very good, the use of C++ and the old version of UML might make it harder for people used to languages with support for real interfaces like Java or C# to understand them. We have tried to address these concerns by reimplementing Martin's examples in Java above. While doing so we could also see how Java encourages ISP with its support of interfaces.

The ISP page at Doodle Project [http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html] has an example in modern UML. The example illustrates how adding new functionality to an existing system might force us to apply ISP to accommodate future changes.

A Java Boutique page [http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html] is available with a very concise and clear example in UML. The example shows how a violation of ISP might manifests itself as one having to provide null implementations for methods from the "fat" interface.

[http://ifacethoughts.net/2006/03/28/interface-segregation-principle/] contains an interesting example because it relates to real-world objects, in this case a cell phone. Modern phones support lots of other functions besides handling phone calls, and each of these functions is handled through different interfaces.

The Object Mentor website also provides a paper with a number of design principles summarized, including ISP [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF]. The advantage of said paper is that the other principles are easily accessible and a designer can compare for advantages and trade-off where multiple principles may be applied.

The extensive use of interfaces in the Java API libraries is an excellent example of ISP because it provides flexibility and extensibility.

Still the best specific examples in our opinion are the ones found on the original paper by Martin.

=Conclusion=

Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.

= Further reading =

[http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=pd_bbs_1?ie=UTF8&s=books&qid=1195404857&sr=8-1 Agile Software Development, Principles, Patterns, and Practices]

[http://www.amazon.com/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1195404857&sr=8-2 Agile Principles, Patterns, and Practices in C#]

[http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign Principles Of Object Oriented Design]

[http://c2.com/cgi/wiki?MaskingInterfaces Masking Interfaces]

[http://c2.com/cgi/wiki?RolePattern Role Pattern]

''Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.''

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-28T22:37:43Z

Jvegafr:

''Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.''

= Introduction =
All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behavior. The Interface Segregation Principle (ISP) provides guidelines for designing interfaces to classes that must provide different services to different clients. The Interface Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.

= Definition =

ISP was originally presented in a paper by Robert C. Martin in his ''Engineering Notebook'' column for the ''C++ Report''. The paper is still available at the Object Mentor website [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)].

The essence of Integration Segregation Principle is that
"Clients should not be forced to depend upon interfaces that they don’t use."

Some other definitions of ISP are:
:"Many client specific interfaces are better than one general purpose interface"
:"The dependency of one class to another one should depend on the smallest possible interface"
:"Make fine grained interfaces that are client specific."

While it can be argued that having a class that has many interfaces violates the Single Responsibility Principle [http://www.objectmentor.com/resources/articles/srp.pdf SRP], there are many instances where having a class implementing different interfaces makes sense, e.g., a graphics class might need to be rendered to screen or serialized to a file.

= Examples =

The following two examples are taken from Martin's paper, but have been ported to Java.

== Security system ==

Suppose you have a security system that has Door objects:

<pre>
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};
</pre>

Now suppose you have a TimedDoor which needs to sound an Alarm when the door has been left open for too long. To implement this functionality the TimerDoor object communicates with a Timer object:

<pre>
public class Timer
{
...
public void Register(int timeout, TimerClient* client) {
...
}
...
};

interface TimerClient
{
public void TimeOut();
};
</pre>

We might be tempted to do the following:

<pre>
interface Door extends TimerClient {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door {
...
}
</pre>

The Door interface has been polluted with the Timer interface in order to provide the Timer interface to TimedDoor and all Door clients now also depend on TimerClient. To void this we can do the following instead:

<pre>
// Unchanged from first listing
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door, TimerClient {
...
}
</pre>

This conforms to ISP by providing the required separate interfaces.

== ATM System ==

Consider an ATM that needs to be very flexible and support screen, braille tablet and speech synthesizer user interfaces. We can abstract the main operations and use an interface which would be implemented by specific UI classes:

<pre>
interface ATM_UI {
void deposit(double amt, double account);
void withdraw(double amt, double account);
void transfer(double amt, double fromAccount, double toAccount);
}

public class BrailleUI implements ATM_UI {
...
}

public class ScreenUI implements ATM_UI {
...
}

public class SpeechUI implements ATM_UI {
...
}
</pre>

Now consider also that each different transaction the ATM can perform are encapsulated in a Transaction object:

<pre>
interface Transaction {
void execute();
}

class DepositTransaction implements Transaction {
void execute() {
atm.deposit(amt, acct);
}
}

class WithdrawalTransaction implements Transaction {
void execute() {
atm.withdraw(amt, acct);
}
}

class TransferTransaction implements Transaction {
void execute() {
atm.withdraw(amt, fromAcct, toAcct);
}
}
</pre>

Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface. To fix the problem we can do the following instead:

<pre>
interface DepositUI {
void deposit(double amt, double account);
}

interface WithdrawalUI {
void withdraw(double amt, double account);
}

interface TransferUI {
void transfer(double amt, double fromAccount, double toAccount);
}

interface ATM_UI extends DepositUI, WithdrawalUI, TransferUI {
...
}
</pre>

And have the individual Transaction objects only reference the needed interfaces.

= Web Resources =

We were unable to find many examples of ISP in the web, the reason might be that ISP is very well explained in the original paper [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)], which has two examples in C++ and an early version of UML. These examples use C++'s multiple inheritance due to the lack of real interfaces in the language. Each interface is defined using an abstract class with pure virtual methods. Even when these examples are very good, the use of C++ and the old version of UML might make it harder for people used to languages with support for real interfaces like Java or C# to understand them. We have tried to address these concerns by reimplementing Martin's examples in Java above. While doing so we could also see how Java encourages ISP with its support of interfaces.

The ISP page at Doodle Project [http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html] has an example in modern UML. The example illustrates how adding new functionality to an existing system might force us to apply ISP to accommodate future changes.

A Java Boutique page [http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html] is available with a very concise and clear example in UML. The example shows how a violation of ISP might manifests itself as one having to provide null implementations for methods from the "fat" interface.

[http://ifacethoughts.net/2006/03/28/interface-segregation-principle/] contains an interesting example because it relates to real-world objects, in this case a cell phone. Modern phones support lots of other functions besides handling phone calls, and each of these functions is handled through different interfaces.

The Object Mentor website also provides a paper with a number of design principles summarized, including ISP [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF]. The advantage of said paper is that the other principles are easily accessible and a designer can compare for advantages and trade-off where multiple principles may be applied.

Still the best examples in our opinion are the ones found on the original paper by Martin.

=Conclusion=

Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.

= Further reading =

[http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=pd_bbs_1?ie=UTF8&s=books&qid=1195404857&sr=8-1 Agile Software Development, Principles, Patterns, and Practices]

[http://www.amazon.com/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1195404857&sr=8-2 Agile Principles, Patterns, and Practices in C#]

[http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign Principles Of Object Oriented Design]

[http://c2.com/cgi/wiki?MaskingInterfaces Masking Interfaces]

[http://c2.com/cgi/wiki?RolePattern Role Pattern]

''Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.''

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-28T21:59:13Z

Jvegafr:

''Take the Interface Segregation principle and catalog the information on it available on the Web. We didn't cover it in class, but you can look it up on the Web or in the ACM DL. Find good descriptions and good, concise, understandable examples. Tell which you consider the best to present to a class.''

= Introduction =
All the basic design principles converge on the use of abstraction for incorporating flexibility using loose coupling behavior. The Interface Segregation Principle (ISP) provides guidelines for designing interfaces to classes that must provide different services to different clients. The Interface Segregation Principle focuses on the cohesiveness of interfaces with respect to the clients that use them.

= Definition =

ISP was originally presented in a paper by Robert C. Martin in his ''Engineering Notebook'' column for the ''C++ Report''. The paper is still available at the Object Mentor website [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)].

The essence of Integration Segregation Principle is that
"Clients should not be forced to depend upon interfaces that they don’t use."

Some other definitions of ISP are:
:"Many client specific interfaces are better than one general purpose interface"
:"The dependency of one class to another one should depend on the smallest possible interface"
:"Make fine grained interfaces that are client specific."

While it can be argued that having a class that has many interfaces violates the Single Responsibility Principle [http://c2.com/cgi/wiki?SingleResponsibilityPrinciple SRP], there are many instances where having a class implementing different interfaces makes sense, e.g., a graphics class might need to be rendered to screen or serialized to a file.

= Examples =

The following two examples are taken from Martin's paper, but have been ported to Java.

== Security system ==

Suppose you have a security system that has Door objects:

<pre>
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};
</pre>

Now suppose you have a TimedDoor which needs to sound an Alarm when the door has been left open for too long. To implement this functionality the TimerDoor object communicates with a Timer object:

<pre>
public class Timer
{
...
public void Register(int timeout, TimerClient* client) {
...
}
...
};

interface TimerClient
{
public void TimeOut();
};
</pre>

We might be tempted to do the following:

<pre>
interface Door extends TimerClient {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door {
...
}
</pre>

The Door interface has been polluted with the Timer interface in order to provide the Timer interface to TimedDoor and all Door clients now also depend on TimerClient. To void this we can do the following instead:

<pre>
// Unchanged from first listing
interface Door {
public void Lock();
public void Unlock();
public boolean IsDoorOpen();
};

class TimedDoor implements Door, TimerClient {
...
}
</pre>

This conforms to ISP by providing the required separate interfaces.

== ATM System ==

Consider an ATM that needs to be very flexible and support screen, braille tablet and speech synthesizer user interfaces. We can abstract the main operations and use an interface which would be implemented by specific UI classes:

<pre>
interface ATM_UI {
void deposit(double amt, double account);
void withdraw(double amt, double account);
void transfer(double amt, double fromAccount, double toAccount);
}

public class BrailleUI implements ATM_UI {
...
}

public class ScreenUI implements ATM_UI {
...
}

public class SpeechUI implements ATM_UI {
...
}
</pre>

Now consider also that each different transaction the ATM can perform are encapsulated in a Transaction object:

<pre>
interface Transaction {
void execute();
}

class DepositTransaction implements Transaction {
void execute() {
atm.deposit(amt, acct);
}
}

class WithdrawalTransaction implements Transaction {
void execute() {
atm.withdraw(amt, acct);
}
}

class TransferTransaction implements Transaction {
void execute() {
atm.withdraw(amt, fromAcct, toAcct);
}
}
</pre>

Notice that this is precisely the situation that the ISP tells us to avoid. Each of the transactions is using a portion of the UI that no other object uses. This creates the possibility that changes to one of the derivatives of Transaction will force corresponding change to the UI, thereby affecting all the other derivatives of Transaction, and every other class that depends upon the UI interface. To fix the problem we can do the following instead:

<pre>
interface DepositUI {
void deposit(double amt, double account);
}

interface WithdrawalUI {
void withdraw(double amt, double account);
}

interface TransferUI {
void transfer(double amt, double fromAccount, double toAccount);
}

interface ATM_UI extends DepositUI, WithdrawalUI, TransferUI {
...
}
</pre>

And have the individual Transaction objects only reference the needed interfaces.

= Web Resources =

We were unable to find many examples of ISP in the web, the reason might be that ISP is very well explained in the original paper [http://www.objectmentor.com/resources/articles/isp.pdf (ISP)], which has two examples in C++ and an early version of UML. These examples use C++'s multiple inheritance due to the lack of real interfaces in the language. Each interface is defined using an abstract class with pure virtual methods. Even when these examples are very good, the use of C++ and the old version of UML might make it harder for people used to languages with support for real interfaces like Java or C# to understand them.

The ISP page at Doodle Project has an example in modern UML [http://doodleproject.sourceforge.net/articles/2001/interfaceSegregationPrinciple.html].

A Java Boutique page is available with a very concise and clear example in UML [http://javaboutique.internet.com/tutorials/JavaOO/interface_segregation.html].

The following page contains an interesting example because it relates to real-world objects, in this case a cell phone [http://ifacethoughts.net/2006/03/28/interface-segregation-principle/].

The Object Mentor website also provides a paper with a number of design principles summarized, including ISP [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.PDF]. The advantage of said paper is that the other principles are easily accessible and a designer can compare for advantages and trade-off where multiple principles may be applied.

Still the best examples in our opinion are the ones found on the original paper by Martin.

=Conclusion=

Interface Segregation Principle's idea is to see that if there are two non-cohesive functionalities, keep them separate, so that they can be used independent of other. This avoids design of fat interfaces, and provides a clear design to the user (client). Break the functionalities into atomic interfaces that can be then individually accessed by the user.

= Further reading =

[http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445/ref=pd_bbs_1?ie=UTF8&s=books&qid=1195404857&sr=8-1 Agile Software Development, Principles, Patterns, and Practices]

[http://www.amazon.com/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1195404857&sr=8-2 Agile Principles, Patterns, and Practices in C#]

''Note: Santosh Gurijala (skgurija) and Agustin Vega-Frias (jvegafr) are the authors of this page.''

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-18T16:56:14Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-18T16:24:16Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-18T16:01:34Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-18T15:06:52Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-17T23:46:46Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-17T23:46:23Z

Jvegafr:

CSC/ECE 517 Fall 2007/wiki3 4 sa

2007-11-17T03:20:36Z

Jvegafr:

This is a skeleton page for Santosh and Agustin to work on Topic 4 of Wiki 3.

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-30T01:13:45Z

Jvegafr:

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

The animation in the following link illustrates how an ORM system works:

[http://www.service-architecture.com/object-relational-mapping/articles/transparent_persistence.html Transparent persistence in object-relational mapping]

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is ''a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores.''[http://www.ksc.com/article1.htm] The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class methods automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

Despite of the shortcomings of some implementations, an ORM systems goes a long way about making application programming simpler and database agnostic.

= Criteria for Selection =

None of the ORM implementations is perfect for all jobs, hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting an ORM system:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Maintainability ===
* What happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML.

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, support, forums, community
* Maturity, frequency of updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= Further reading =

An excellent introduction to ORM can be found at http://www.chimu.com/publications/objectRelational/, a PDF version can be downloaded from http://www.chimu.com/publications/objectRelational/objectRelational.pdf.

= References =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-30T00:21:52Z

Jvegafr: /* How ORM works? */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

The animation in the following link illustrates how an ORM system works:

[http://www.service-architecture.com/object-relational-mapping/articles/transparent_persistence.html Transparent persistence in object-relational mapping]

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class methods automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

= Criteria for Selection =

None of the ORM implementations is perfect for all jobs, hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting an ORM system:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Maintainability ===
* What happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML.

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, support, forums, community
* Maturity, frequency of updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= Further reading =

An excellent introduction to ORM can be found at http://www.chimu.com/publications/objectRelational/, a PDF version can be downloaded from http://www.chimu.com/publications/objectRelational/objectRelational.pdf.

= References =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-25T00:35:06Z

Jvegafr: /* Rails Active Record */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class methods automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

= Criteria for Selection =

None of the ORM implementations is perfect for all jobs, hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting an ORM system:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Maintainability ===
* What happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML.

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, support, forums, community
* Maturity, frequency of updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= Further reading =

An excellent introduction to ORM can be found at http://www.chimu.com/publications/objectRelational/, a PDF version can be downloaded from http://www.chimu.com/publications/objectRelational/objectRelational.pdf.

= References =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-25T00:33:32Z

Jvegafr:

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements uses Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class structures automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

= Criteria for Selection =

None of the ORM implementations is perfect for all jobs, hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting an ORM system:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Maintainability ===
* What happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML.

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, support, forums, community
* Maturity, frequency of updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= Further reading =

An excellent introduction to ORM can be found at http://www.chimu.com/publications/objectRelational/, a PDF version can be downloaded from http://www.chimu.com/publications/objectRelational/objectRelational.pdf.

= References =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-25T00:28:07Z

Jvegafr: /* Criteria for Selection */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements uses Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class structures automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

= Criteria for Selection =

None of the ORM implementations is perfect for all jobs, hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting an ORM system:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML.

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= Other links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-25T00:25:28Z

Jvegafr: /* Comparing ORM systems */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements uses Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class structures automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is very important consideration in regards to maintainability and learning curve. As far as flexibility and ease of use are concerned the ORM implementations for dynamic languages clearly win.

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= Other links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-24T02:14:52Z

Jvegafr:

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping metadata (e.g. XML mapping files in Java Hibernate). In languages that support metaprogramming at runtime or compile time the mapping can be done automatically from information gathered from the database schema.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database by manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= Design Patterns addressing ORM =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

Active Record is part of the pattern language presented by Fowler in the book [http://www.amazon.com/exec/obidos/ASIN/0321127420 Patterns of Enterprise Application Architecture]. A summary of the other patterns in the language can be found [http://www.martinfowler.com/eaaCatalog/ here].

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/].

== Crossing Chasms ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

The pattern language includes patterns that deal with ORM from the architectural and behavioral points of view.

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

= ORM implementations =

An extensive list of ORM systems divided by language targeted can be found [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software here]. A shorter representative list follows.

== Rails Active Record ==

The Rails Active Record library implements uses Active Record and related patterns as a foundation to provide an extremely elegant and succinct ORM system. By using the power of metaprogramming available in Ruby, the system is able to gather information from the database and generates class structures automatically from the database schema.

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM interface for Java.

Hibernate supports inheritance, polymorphism, composition and the Java collections framework. It uses a dual-layer cache architecture to optimize performance.

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html] for mapping, caching, logging, etc.

== Apache ObJectRelationalBridge - OJB ==

OJB [http://db.apache.org/ojb/] allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS. Supports for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a base class or interface will return matches from derived classes, even if they are mapped to different database tables. OJB uses an XML based Object/Relational mapping.

== Database Template Library ==

The DTL [http://dtemplatelib.sourceforge.net/] is a C++ ORM system that aims to provide a database abstraction similar to the Standard Template Library. The mapping is performed using macros and template metaprogramming.

== SQLObject ==

SQLObject [http://sqlobject.org/] is an ORM for Python. Like the Ruby On Rails' Active Record library it takes advantage of the reflection and dynamic characteristics of Python to generate class structures from the database schemas

= Comparing ORM systems =

The major difference between the pattern languages and the specific implementations is that the former attempt to address other issues besides how to map the data to objects and vice versa. For example Crossing Chasms includes a Table Design Pattern that addresses the question of when is the best time to design the database schema. This is an important consideration specially for systems that will evolve, since it is harder to make big changes to the database schema once the system is in use. The pattern solves the problem by requiring a first-pass object behavioral modeling. It makes sense because in a new system we want to store the state of our objects, not adapt our objects to a specific database schema.

Configuration is another difference between systems. While some languages support trivial configuration through their metaprogramming capabilities others require extensive configuration. This is also very important in regards to the learning curve.

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= Other links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
# http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-23T02:02:54Z

Jvegafr: /* Oracle TopLink */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

A comprehensive list of ORM systems by language is available at [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software]

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping data (e.g. XML mapping files in Java Hibernate). In languages that support meta programming at runtime or compile time the mapping can be done automatically from information gathered from the database.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database my manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= ORM Implementations =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/], which also adds associations through the use of meta programming macros and inheritance with the Single Table Inheritance pattern [http://martinfowler.com/eaaCatalog/singleTableInheritance.html].

The major features of the Rails Active Record implementation as described in [1] are:
* Automated mapping between classes and tables, attributes and columns.
* Associations between objects controlled by simple meta-programming macros.
* Aggregations of value objects controlled by simple meta-programming macros.
* Validation rules that can differ for new or existing objects.
* Acts that can make records work as lists or trees
* Callbacks as methods or queues on the entire life cycle (instantiation, saving, destroying, validating, etc).
* Observers for the entire life cycle
* Inheritance hierarchies
* Transaction support on both a database and object level.
* Reflections on columns, associations, and aggregations
* Direct manipulation (instead of service invocation like Java Hibernate)
* Database abstraction through simple adapters (~100 lines) with a shared connector
* Logging support for Log4r and Logger

== Crossing Chasms pattern ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM for Java.

Hibernate supports the following key OO features
* Hibernate supports natural OO idioms; inheritance, polymorphism, composition and the Java collections framework
* It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
* There is no extra code generation or bytecode processing steps in the build procedure
* Hibernate is extremely high performance, has a dual-layer cache architecture, and may be used in a cluster
* Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
* Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
* Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group

== Oracle TopLink ==

Oracle TopLink [http://www.oracle.com/technology/products/ias/toplink/index.html] is a proprietary ORM system developed by Oracle. It supports the Java Persistence API and provides extensions [http://www.oracle.com/technology/products/ias/toplink/jpa/resources/toplink-jpa-extensions.html].

== JDO ==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,
* Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
* Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
* Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
* Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
* Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.
[http://java.sun.com/jdo]

== Java Persistence API ==

The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. The Java Persistence API contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers. The Java Persistence API is now the preferred persistence API for use with EJB 3.0 applications.
[http://java.sun.com/javaee/technologies/persistence.jsp]

== Apache ObJectRelationalBridge - OJB ==

* The PersistenceBroker kernel API and all top-level APIs (ODMG, OTM, JDO) allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS
* Transparent persistence: classes does not have to inherit from any OJB base class nor implement a special interface. OJB delivers pure transparent persistence for POJOs.
* Scalable architecture that allows to build massively distributed and clustered systems.
* Quality assurance taken seriously: More than 800 JUnit Test Cases for regression tests. JUnit tests are integrated into the build scripts and used as quality assurance for daily development.
* Support for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a baseclass or interface will return matches from derived classes, even if they are mapped to different DB-tables
* Support for persistent object caching. Different caching strategies and distributed caches.
* OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
* OJB provides several advanced O/R features like Object Caching, lazy materialization through virtual proxies and distributed lock-management with configurable Transaction-Isolation levels. Optimistic and pessimistic locking is supported.
* OJB provides a flexible configuration and plugin mechanism that allows to select from set of predefined components or to implement your own extensions and plugins.
[http://db.apache.org/ojb/]

== Enterprise Objects Framework (Apple) ==

Enterprise Objects Framework provides tools for defining an object model and mapping it to a data model. This allows to create objects that encapsulate both data and the methods for operating on that data, while taking advantage of the data access services provided by the Framework that make it possible for these objects to persist in a relational database.
The flexible, three-tier architecture provided by the Framework allows to build robust, scalable, client/server applications. Objects at each of the three tiers (user interface, enterprise objects, and data store) can be deployed to take advantage of network resources. For example, data might be stored in a relational database running on a fault-tolerant database server with gigabytes of disk storage, while enterprise objects run on high-end compute servers. Partitioning the application to make best use of available resources allows complex applications to achieve maximum performance.
The portions of the Framework can be used selectively to meet specific application requirements. For example, the components that provide users with the ability to interactively manipulate enterprise objects can be used by a non-database application to handle user interface refresh and undo. We can use a custom data store (such as a flat-file system) in place of a relational database to store data for enterprise objects. Or we can make use of the database adapters separate from the rest of the Framework components to provide direct access to relational databases for your applications.
[http://developer.apple.com/]

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= External links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-23T01:51:07Z

Jvegafr: /* Hibernate */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

A comprehensive list of ORM systems by language is available at [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software]

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping data (e.g. XML mapping files in Java Hibernate). In languages that support meta programming at runtime or compile time the mapping can be done automatically from information gathered from the database.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database my manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= ORM Implementations =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/], which also adds associations through the use of meta programming macros and inheritance with the Single Table Inheritance pattern [http://martinfowler.com/eaaCatalog/singleTableInheritance.html].

The major features of the Rails Active Record implementation as described in [1] are:
* Automated mapping between classes and tables, attributes and columns.
* Associations between objects controlled by simple meta-programming macros.
* Aggregations of value objects controlled by simple meta-programming macros.
* Validation rules that can differ for new or existing objects.
* Acts that can make records work as lists or trees
* Callbacks as methods or queues on the entire life cycle (instantiation, saving, destroying, validating, etc).
* Observers for the entire life cycle
* Inheritance hierarchies
* Transaction support on both a database and object level.
* Reflections on columns, associations, and aggregations
* Direct manipulation (instead of service invocation like Java Hibernate)
* Database abstraction through simple adapters (~100 lines) with a shared connector
* Logging support for Log4r and Logger

== Crossing Chasms pattern ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

== Hibernate ==

Hibernate is a Java ORM and query service [http://www.hibernate.org]. The current version of the system can be used using different APIs:

* '''Native'''. The user uses XML metadata to help the Hibernate subsystem map table data and relationship to application classes and objects.
* '''Java Persistence API'''. Hibernate implements the Java Persistence API [http://java.sun.com/javaee/technologies/persistence.jsp] which defines a standard ORM for Java.

Hibernate supports the following key OO features
* Hibernate supports natural OO idioms; inheritance, polymorphism, composition and the Java collections framework
* It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
* There is no extra code generation or bytecode processing steps in the build procedure
* Hibernate is extremely high performance, has a dual-layer cache architecture, and may be used in a cluster
* Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
* Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
* Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group

== Oracle TopLink ==

Oracle TopLink delivers complete Java Persistance platform by providing following main features:
* Access relational data using JPA and many advanced object-relational extensions
* Efficiently manipulate XML through a Java domain model using JAXB
* Interact with unstructured data through Service Data Objects (SDO)
* Expose relational datbases flexibly using Web Services
[http://www.oracle.com/technology/products/ias/toplink/index.html]

== JDO ==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,
* Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
* Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
* Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
* Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
* Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.
[http://java.sun.com/jdo]

== Java Persistence API ==

The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. The Java Persistence API contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers. The Java Persistence API is now the preferred persistence API for use with EJB 3.0 applications.
[http://java.sun.com/javaee/technologies/persistence.jsp]

== Apache ObJectRelationalBridge - OJB ==

* The PersistenceBroker kernel API and all top-level APIs (ODMG, OTM, JDO) allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS
* Transparent persistence: classes does not have to inherit from any OJB base class nor implement a special interface. OJB delivers pure transparent persistence for POJOs.
* Scalable architecture that allows to build massively distributed and clustered systems.
* Quality assurance taken seriously: More than 800 JUnit Test Cases for regression tests. JUnit tests are integrated into the build scripts and used as quality assurance for daily development.
* Support for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a baseclass or interface will return matches from derived classes, even if they are mapped to different DB-tables
* Support for persistent object caching. Different caching strategies and distributed caches.
* OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
* OJB provides several advanced O/R features like Object Caching, lazy materialization through virtual proxies and distributed lock-management with configurable Transaction-Isolation levels. Optimistic and pessimistic locking is supported.
* OJB provides a flexible configuration and plugin mechanism that allows to select from set of predefined components or to implement your own extensions and plugins.
[http://db.apache.org/ojb/]

== Enterprise Objects Framework (Apple) ==

Enterprise Objects Framework provides tools for defining an object model and mapping it to a data model. This allows to create objects that encapsulate both data and the methods for operating on that data, while taking advantage of the data access services provided by the Framework that make it possible for these objects to persist in a relational database.
The flexible, three-tier architecture provided by the Framework allows to build robust, scalable, client/server applications. Objects at each of the three tiers (user interface, enterprise objects, and data store) can be deployed to take advantage of network resources. For example, data might be stored in a relational database running on a fault-tolerant database server with gigabytes of disk storage, while enterprise objects run on high-end compute servers. Partitioning the application to make best use of available resources allows complex applications to achieve maximum performance.
The portions of the Framework can be used selectively to meet specific application requirements. For example, the components that provide users with the ability to interactively manipulate enterprise objects can be used by a non-database application to handle user interface refresh and undo. We can use a custom data store (such as a flat-file system) in place of a relational database to store data for enterprise objects. Or we can make use of the database adapters separate from the rest of the Framework components to provide direct access to relational databases for your applications.
[http://developer.apple.com/]

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= External links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-23T01:31:32Z

Jvegafr: /* Crossing Chasms pattern */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

A comprehensive list of ORM systems by language is available at [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software]

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping data (e.g. XML mapping files in Java Hibernate). In languages that support meta programming at runtime or compile time the mapping can be done automatically from information gathered from the database.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database my manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= ORM Implementations =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/], which also adds associations through the use of meta programming macros and inheritance with the Single Table Inheritance pattern [http://martinfowler.com/eaaCatalog/singleTableInheritance.html].

The major features of the Rails Active Record implementation as described in [1] are:
* Automated mapping between classes and tables, attributes and columns.
* Associations between objects controlled by simple meta-programming macros.
* Aggregations of value objects controlled by simple meta-programming macros.
* Validation rules that can differ for new or existing objects.
* Acts that can make records work as lists or trees
* Callbacks as methods or queues on the entire life cycle (instantiation, saving, destroying, validating, etc).
* Observers for the entire life cycle
* Inheritance hierarchies
* Transaction support on both a database and object level.
* Reflections on columns, associations, and aggregations
* Direct manipulation (instead of service invocation like Java Hibernate)
* Database abstraction through simple adapters (~100 lines) with a shared connector
* Logging support for Log4r and Logger

== Crossing Chasms pattern ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design conference [PLoPD], the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

== Hibernate ==

Hibernate supports key OO features
* Hibernate supports natural OO idiom; inheritance, polymorphism, composition and the Java collections framework
* It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
* There is no extra code generation or bytecode processing steps in build procedure
* Hibernate is extremely performant, has a dual-layer cache architecture, and may be used in a cluster
* Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
* Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
* Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group
[http://www.hibernate.org]

== Oracle TopLink ==

Oracle TopLink delivers complete Java Persistance platform by providing following main features:
* Access relational data using JPA and many advanced object-relational extensions
* Efficiently manipulate XML through a Java domain model using JAXB
* Interact with unstructured data through Service Data Objects (SDO)
* Expose relational datbases flexibly using Web Services
[http://www.oracle.com/technology/products/ias/toplink/index.html]

== JDO ==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,
* Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
* Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
* Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
* Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
* Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.
[http://java.sun.com/jdo]

== Java Persistence API ==

The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. The Java Persistence API contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers. The Java Persistence API is now the preferred persistence API for use with EJB 3.0 applications.
[http://java.sun.com/javaee/technologies/persistence.jsp]

== Apache ObJectRelationalBridge - OJB ==

* The PersistenceBroker kernel API and all top-level APIs (ODMG, OTM, JDO) allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS
* Transparent persistence: classes does not have to inherit from any OJB base class nor implement a special interface. OJB delivers pure transparent persistence for POJOs.
* Scalable architecture that allows to build massively distributed and clustered systems.
* Quality assurance taken seriously: More than 800 JUnit Test Cases for regression tests. JUnit tests are integrated into the build scripts and used as quality assurance for daily development.
* Support for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a baseclass or interface will return matches from derived classes, even if they are mapped to different DB-tables
* Support for persistent object caching. Different caching strategies and distributed caches.
* OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
* OJB provides several advanced O/R features like Object Caching, lazy materialization through virtual proxies and distributed lock-management with configurable Transaction-Isolation levels. Optimistic and pessimistic locking is supported.
* OJB provides a flexible configuration and plugin mechanism that allows to select from set of predefined components or to implement your own extensions and plugins.
[http://db.apache.org/ojb/]

== Enterprise Objects Framework (Apple) ==

Enterprise Objects Framework provides tools for defining an object model and mapping it to a data model. This allows to create objects that encapsulate both data and the methods for operating on that data, while taking advantage of the data access services provided by the Framework that make it possible for these objects to persist in a relational database.
The flexible, three-tier architecture provided by the Framework allows to build robust, scalable, client/server applications. Objects at each of the three tiers (user interface, enterprise objects, and data store) can be deployed to take advantage of network resources. For example, data might be stored in a relational database running on a fault-tolerant database server with gigabytes of disk storage, while enterprise objects run on high-end compute servers. Partitioning the application to make best use of available resources allows complex applications to achieve maximum performance.
The portions of the Framework can be used selectively to meet specific application requirements. For example, the components that provide users with the ability to interactively manipulate enterprise objects can be used by a non-database application to handle user interface refresh and undo. We can use a custom data store (such as a flat-file system) in place of a relational database to store data for enterprise objects. Or we can make use of the database adapters separate from the rest of the Framework components to provide direct access to relational databases for your applications.
[http://developer.apple.com/]

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= External links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-23T01:07:34Z

Jvegafr: /* Active Record */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

A comprehensive list of ORM systems by language is available at [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software]

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping data (e.g. XML mapping files in Java Hibernate). In languages that support meta programming at runtime or compile time the mapping can be done automatically from information gathered from the database.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database my manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= ORM Implementations =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

The best example of the implementation of the pattern is found in the Rails framework [http://ar.rubyonrails.com/], which also adds associations through the use of meta programming macros and inheritance with the Single Table Inheritance pattern [http://martinfowler.com/eaaCatalog/singleTableInheritance.html].

The major features of the Rails Active Record implementation as described in [1] are:
* Automated mapping between classes and tables, attributes and columns.
* Associations between objects controlled by simple meta-programming macros.
* Aggregations of value objects controlled by simple meta-programming macros.
* Validation rules that can differ for new or existing objects.
* Acts that can make records work as lists or trees
* Callbacks as methods or queues on the entire life cycle (instantiation, saving, destroying, validating, etc).
* Observers for the entire life cycle
* Inheritance hierarchies
* Transaction support on both a database and object level.
* Reflections on columns, associations, and aggregations
* Direct manipulation (instead of service invocation like Java Hibernate)
* Database abstraction through simple adapters (~100 lines) with a shared connector
* Logging support for Log4r and Logger

== Crossing Chasms pattern ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design [PLoPD] conference, the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

== Hibernate ==

Hibernate supports key OO features
* Hibernate supports natural OO idiom; inheritance, polymorphism, composition and the Java collections framework
* It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
* There is no extra code generation or bytecode processing steps in build procedure
* Hibernate is extremely performant, has a dual-layer cache architecture, and may be used in a cluster
* Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
* Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
* Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group
[http://www.hibernate.org]

== Oracle TopLink ==

Oracle TopLink delivers complete Java Persistance platform by providing following main features:
* Access relational data using JPA and many advanced object-relational extensions
* Efficiently manipulate XML through a Java domain model using JAXB
* Interact with unstructured data through Service Data Objects (SDO)
* Expose relational datbases flexibly using Web Services
[http://www.oracle.com/technology/products/ias/toplink/index.html]

== JDO ==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,
* Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
* Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
* Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
* Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
* Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.
[http://java.sun.com/jdo]

== Java Persistence API ==

The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. The Java Persistence API contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers. The Java Persistence API is now the preferred persistence API for use with EJB 3.0 applications.
[http://java.sun.com/javaee/technologies/persistence.jsp]

== Apache ObJectRelationalBridge - OJB ==

* The PersistenceBroker kernel API and all top-level APIs (ODMG, OTM, JDO) allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS
* Transparent persistence: classes does not have to inherit from any OJB base class nor implement a special interface. OJB delivers pure transparent persistence for POJOs.
* Scalable architecture that allows to build massively distributed and clustered systems.
* Quality assurance taken seriously: More than 800 JUnit Test Cases for regression tests. JUnit tests are integrated into the build scripts and used as quality assurance for daily development.
* Support for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a baseclass or interface will return matches from derived classes, even if they are mapped to different DB-tables
* Support for persistent object caching. Different caching strategies and distributed caches.
* OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
* OJB provides several advanced O/R features like Object Caching, lazy materialization through virtual proxies and distributed lock-management with configurable Transaction-Isolation levels. Optimistic and pessimistic locking is supported.
* OJB provides a flexible configuration and plugin mechanism that allows to select from set of predefined components or to implement your own extensions and plugins.
[http://db.apache.org/ojb/]

== Enterprise Objects Framework (Apple) ==

Enterprise Objects Framework provides tools for defining an object model and mapping it to a data model. This allows to create objects that encapsulate both data and the methods for operating on that data, while taking advantage of the data access services provided by the Framework that make it possible for these objects to persist in a relational database.
The flexible, three-tier architecture provided by the Framework allows to build robust, scalable, client/server applications. Objects at each of the three tiers (user interface, enterprise objects, and data store) can be deployed to take advantage of network resources. For example, data might be stored in a relational database running on a fault-tolerant database server with gigabytes of disk storage, while enterprise objects run on high-end compute servers. Partitioning the application to make best use of available resources allows complex applications to achieve maximum performance.
The portions of the Framework can be used selectively to meet specific application requirements. For example, the components that provide users with the ability to interactively manipulate enterprise objects can be used by a non-database application to handle user interface refresh and undo. We can use a custom data store (such as a flat-file system) in place of a relational database to store data for enterprise objects. Or we can make use of the database adapters separate from the rest of the Framework components to provide direct access to relational databases for your applications.
[http://developer.apple.com/]

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= External links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-23T00:56:53Z

Jvegafr: /* How ORM works? */

''Object-relational mapping. Ruby's ActiveRecord is one attempt to allow an object-oriented program to use a relational database. The Crossing Chasms pattern is another. Look up several approaches to mapping relational databases to o-o programs, include hyperlinks to all of them, and explain how they differ. Report on the strengths of various approaches (making sure to credit the authors for their insights).''

__TOC__

= Introduction =

== What is ORM? ==
Object Relational Mapping (ORM) is a technique used in software systems that use an object-oriented language in their application domain and a relational database to store persistent data from the objects they use. The mapping is required due to the differences in representation. The database uses tables and foreign keys for its representation of data and relationships where the application uses objects and references and/or pointers.
For some time proponents of Object-Oriented Database Management Systems (ODBMS) have argued that this is similar to breaking up a car to its pieces before storing it in the garage and putting it together again after taking it out. Whereas in an object database you store or retrieve the whole car at once.

A comprehensive list of ORM systems by language is available at [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software List of object-relational mapping software]

== How ORM works? ==
Typical ORM systems will map one row in a table in the database to an object in the application and vice versa. In static languages the mapping is done manually or it is automated with a preprocessor or with external mapping data (e.g. XML mapping files in Java Hibernate). In languages that support meta programming at runtime or compile time the mapping can be done automatically from information gathered from the database.

ORM systems typically provide the programmer with object factories that map class method calls to SQL queries that retrieve objects from the database. They also provide methods to store the object data back in the database after updates in the application. This ability of an ORM to allow the programmer to interact with the database my manipulating objects in the programming language is referred to as ''transparent persistence'', because the database access is seamless to the programmer.

= ORM Implementations =

== Active Record ==

The Active Record pattern describes the most basic mapping of one object per table row, or as described by its author Martin Fowler: ''An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.'' [http://www.martinfowler.com/eaaCatalog/activeRecord.html]

The major features of the Rails Active Record implementation are:
* Automated mapping between classes and tables, attributes and columns.
* Associations between objects controlled by simple meta-programming macros.
* Aggregations of value objects controlled by simple meta-programming macros.
* Validation rules that can differ for new or existing objects.
* Acts that can make records work as lists or trees
* Callbacks as methods or queues on the entire life cycle (instantiation, saving, destroying, validating, etc).
* Observers for the entire life cycle
* Inheritance hierarchies
* Transaction support on both a database and object level.
* Reflections on columns, associations, and aggregations
* Direct manipulation (instead of service invocation like Java Hibernate)
* Database abstraction through simple adapters (~100 lines) with a shared connector
* Logging support for Log4r and Logger

One of the best examples of the implementation of the pattern is found in the Rails framework (http://ar.rubyonrails.com/).

== Crossing Chasms pattern ==

Crossing Chasms is a large pattern language that as a whole addresses the issues faced by teams trying to build large client-server systems using Object Technology and Relational data stores. The authors, Kyle Brown and Bruce Whitenack, originally presented the language at the Second Pattern Languages of Program Design [PLoPD] conference, the proceedings of the conference were published as the book [http://www.amazon.com/Pattern-Languages-Program-Software-Patterns/dp/0201895277 Pattern Languages of Program Design 2].

Currently there is little information available online. The best articles still available are:

* [http://www.ksc.com/article1.htm Crossing Chasms: The Architectural Patterns]
* [http://www.ksc.com/article2.htm A Pattern Language for Relational Databases and Smalltalk]
* [http://www.ksc.com/article5.htm Crossing Chasms: A Pattern Language for Object-RDBMS Integration "The Static Patterns"]
* [http://www.smallmemory.com/almanac/BrownEtc96b.html Crossing Chasms: A Pattern Language for Object-RDBMS Integration]
* [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms]

== Hibernate ==

Hibernate supports key OO features
* Hibernate supports natural OO idiom; inheritance, polymorphism, composition and the Java collections framework
* It supports fine-grained object models - a rich variety of mappings for collections and dependent objects
* There is no extra code generation or bytecode processing steps in build procedure
* Hibernate is extremely performant, has a dual-layer cache architecture, and may be used in a cluster
* Hibernate addresses both sides of the problem; not only how to get objects into the database, but also how to get them out again
* Hibernate supports both long-lived persistence contexts, detach/reattach of objects, and takes care of optimistic locking automatically
* Hibernate implements the Java Persistence management API and object/relational mapping options (EJB 3.0), two members of the Hibernate team are active in the expert group
[http://www.hibernate.org]

== Oracle TopLink ==

Oracle TopLink delivers complete Java Persistance platform by providing following main features:
* Access relational data using JPA and many advanced object-relational extensions
* Efficiently manipulate XML through a Java domain model using JAXB
* Interact with unstructured data through Service Data Objects (SDO)
* Expose relational datbases flexibly using Web Services
[http://www.oracle.com/technology/products/ias/toplink/index.html]

== JDO ==
The Java Data Objects (JDO) API is a standard interface-based Java model abstraction of persistence,
* Application programmers can focus on their domain object model and leave the details of persistence (field-by-field storage of objects) to the JDO implementation.
* Applications written with the JDO API can be run on multiple implementations without recompiling or changing source code. Metadata, which describes persistence behavior external to the Java source code including most commonly used features of O/R mapping, is highly portable.
* Applications written with the JDO API are independent of the underlying database. JDO implementations support many different kinds of transactional data stores, including relational and object databases, XML, flat files, and others.
* Application programmers delegate the details of persistence to the JDO implementation, which can optimize data access patterns for optimal performance.
* Applications can take advantage of EJB features such as remote message processing, automatic distributed transaction coordination, and security, using the same domain object models throughout the enterprise.
[http://java.sun.com/jdo]

== Java Persistence API ==

The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. The Java Persistence API contains a full object/relational mapping specification supporting the use of Java language metadata annotations and/or XML descriptors to define the mapping between Java objects and a relational database. It supports a rich, SQL-like query language (which is a significant extension upon EJB QL) for both static and dynamic queries. It also supports the use of pluggable persistence providers. The Java Persistence API is now the preferred persistence API for use with EJB 3.0 applications.
[http://java.sun.com/javaee/technologies/persistence.jsp]

== Apache ObJectRelationalBridge - OJB ==

* The PersistenceBroker kernel API and all top-level APIs (ODMG, OTM, JDO) allows Java Programmers to store and retrieve Java Objects in/from (any) JDBC-compliant RDBMS
* Transparent persistence: classes does not have to inherit from any OJB base class nor implement a special interface. OJB delivers pure transparent persistence for POJOs.
* Scalable architecture that allows to build massively distributed and clustered systems.
* Quality assurance taken seriously: More than 800 JUnit Test Cases for regression tests. JUnit tests are integrated into the build scripts and used as quality assurance for daily development.
* Support for Polymorphism and Extents. You can use Interface-types and abstract classes as attribute types in your persistent classes. Queries are also aware of extents: A query against a baseclass or interface will return matches from derived classes, even if they are mapped to different DB-tables
* Support for persistent object caching. Different caching strategies and distributed caches.
* OJB uses an XML based Object/Relational mapping. The mapping resides in a dynamic MetaData layer, which can be manipulated at runtime through a simple Meta-Object-Protocol (MOP) to change the behaviour of the persistence kernel.
* OJB provides several advanced O/R features like Object Caching, lazy materialization through virtual proxies and distributed lock-management with configurable Transaction-Isolation levels. Optimistic and pessimistic locking is supported.
* OJB provides a flexible configuration and plugin mechanism that allows to select from set of predefined components or to implement your own extensions and plugins.
[http://db.apache.org/ojb/]

== Enterprise Objects Framework (Apple) ==

Enterprise Objects Framework provides tools for defining an object model and mapping it to a data model. This allows to create objects that encapsulate both data and the methods for operating on that data, while taking advantage of the data access services provided by the Framework that make it possible for these objects to persist in a relational database.
The flexible, three-tier architecture provided by the Framework allows to build robust, scalable, client/server applications. Objects at each of the three tiers (user interface, enterprise objects, and data store) can be deployed to take advantage of network resources. For example, data might be stored in a relational database running on a fault-tolerant database server with gigabytes of disk storage, while enterprise objects run on high-end compute servers. Partitioning the application to make best use of available resources allows complex applications to achieve maximum performance.
The portions of the Framework can be used selectively to meet specific application requirements. For example, the components that provide users with the ability to interactively manipulate enterprise objects can be used by a non-database application to handle user interface refresh and undo. We can use a custom data store (such as a flat-file system) in place of a relational database to store data for enterprise objects. Or we can make use of the database adapters separate from the rest of the Framework components to provide direct access to relational databases for your applications.
[http://developer.apple.com/]

= Criteria for Selection =

There is no perfect single tool exists. Hence the most important thing when searching for the right tool is to define precisely which criteria are essential. Following is the summary of criteria which can be considered while selecting the ORM product:

== ORM specific criteria ==
=== Basic features: ===
* Be able to use inheritance, create hierarchies between entities, and use polymorphism (we are using objects!). The tools can support a variety of combinations for tables and classes to allow these mechanisms.
* Handle any type of relations (1-1, 1-n, n-n)
* Support for transactions
* Aggregates (equivalent to SQL's SUM, AVG, MIN, MAX, COUNT)
* Support for grouping (SQL's GROUP BY)
* Supported databases. A big advantage of mapping tools is that they provide an abstraction of the underlying database engine. Most of them allow switching easily between RDBMSs
=== Flexibility ===
* Customization of queries. HQL is a strong point of Hibernate/NHibernate. We could also wish a dynamic mapping to be possible from developer provided SQL queries.
* Support any type of SQL joins (inner join, outer join)
* Be able to map a single object to data coming from multiple tables (joins, views). And Be able to dispatch the data from a single table to multiple objects.
=== Performance ===
* Lazy loading - he loading of some data is deferred until it's needed. For the data through relations and for some columns.
* Cache dynamically generated queries and Cache some data to avoid too many calls to the data source.
* Handle cascade updates. Deleting a master record should delete the linked details if wished so.
=== Evolution: ===
* Maintainability - what happens if the database schema changes? If I need to add a new collection?
* Possibility to move to a new mapping tool
* Serialization. Serialization can be used to persist data outside of the database. Serialization can be done into a binary format, or more important, in XML (

== Non ORM specific criteria ==
* Price
* Performance
* Resource consumption (memory)
* Scalability
* Complexity (or simplicity...)
* Ease of use, time to be up and running
* Documentation quality, Support, forums, community
* Maturity, Frequency of the updates, bug fixes, evolutions
* Vendor's reputation and stability
* Support for multiple platforms

= References =

= Further reading =

= External links =

# http://ar.rubyonrails.com/
# http://www.ksc.com/article5.htm
# http://www.hibernate.org
# http://www.oracle.com/technology/products/ias/toplink/index.html
# http://java.sun.com/jdo
# http://java.sun.com/javaee/technologies/persistence.jsp
# http://db.apache.org/ojb/
# http://developer.apple.com/
# http://en.wikipedia.org/wiki/Object-relational_mapping
# http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T01:48:46Z

Jvegafr: /* What is ORM? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T01:40:20Z

Jvegafr: /* How ORM works? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T01:24:37Z

Jvegafr: /* Active Record */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T01:22:07Z

Jvegafr: /* Crossing Chasms pattern */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T00:53:33Z

Jvegafr: /* Active Record */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T00:43:26Z

Jvegafr: /* Ruby's Active Record */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T00:35:28Z

Jvegafr: /* How ORM works? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-22T00:12:42Z

Jvegafr: /* What is ORM? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-21T14:48:10Z

Jvegafr: /* What is ORM? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-21T14:45:25Z

Jvegafr: /* What is ORM? */

CSC/ECE 517 Fall 2007/wiki2 2 22

2007-10-21T14:45:04Z

Jvegafr: /* What is ORM? */

CSC/ECE 517 Fall 2007/wiki1b 8 sa

2007-10-11T01:15:05Z

Jvegafr:

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

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 succinct, Java requires more boilerplate code due to the static nature of the language
# Closures make it trivial to add parameters to the strategy 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-10T19:44:26Z

Jvegafr: /* Real World Case Study */

= 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.
# 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.

= 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-10T19:40:53Z

Jvegafr: /* Real World Case Study */

= 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.
# 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.

= 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> instance containing the source and destination paths (the context class). 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 strategy). The application then has three different file operations: <code>CopyOperation</code>, <code>RenameOperation</code> and <code>ReencodeOperation</code> (the concrete strategies). 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-10T19:31:19Z

Jvegafr: /* 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 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.
# 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.

= 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 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-10T19:30:25Z

Jvegafr: /* 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 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 ===

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.

[[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.

=== 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.
# 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.

= 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 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-10T19:29:11Z

Jvegafr:

= 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 ===

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.

=== 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.
# 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.

= 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 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-10T19:25:00Z

Jvegafr: /* 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 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.

== 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.
# 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-09-30T19:48:49Z

Jvegafr:

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
|-
| 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'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-30T19:30:00Z

Jvegafr:

ote: 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
|-
| 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'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-30T15:53:39Z

Jvegafr:

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 + ",");
}
}

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}." }

# 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
|-
| More boilerplate code due to the static nature of the language
| More succint code
|-
| Parameters to strategies must be instance or class variables
| Closures make it trivial to add parameters to the stategies
|-
| 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-30T15:51:57Z

Jvegafr:

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.

<code>
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 + ",");
}
}

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();
}
}
}
</code>

== Ruby's Solution ==

Here is the Ruby implementation of the playlist synchronization application.

<copy>
# 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}." }

# 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() }
</copy>

= 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
|-
| More boilerplate code due to the static nature of the language
| More succint code
|-
| Parameters to strategies must be instance or class variables
| Closures make it trivial to add parameters to the stategies
|-
| 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]