Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:21:52Z

Bsampat2: /* Application */

=Overview=

The purpose of this Wikipedia page is to give the readers a list of references that explain the Strategy pattern. The references given in this page will give a complete knowledge of this pattern. Further, with each references given in this page a briefing of what it covers, the programming language used and the purpose that it serves is mentioned.

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern over Switch statements=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm <ref name="Difference"> http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx </ref> at run time. This explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern over Inheritance=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

Strategy pattern is used in real life appliactions <ref name="Application"> [http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf </ref>. This article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code but demonstrates the importance of strategy pattern in real life.

=Conclusion=

The page includes references that describe the usefulness, advantages and comparison of the Strategy pattern with other methodologies.
The reader can get a complete knowledge of the pattern by following the references given.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:21:43Z

Bsampat2: /* Application */

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:18:42Z

Bsampat2: /* Strategy Pattern, Directory of sites */

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:10:52Z

Bsampat2: /* Strategy Pattern and Inheritance, a comparison */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern over Switch statements=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm <ref name="Difference"> http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx </ref> at run time. This explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern over Inheritance=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

Strategy pattern is used in real life appliactions <ref name="Application"> [http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf </ref>. This article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code but demonstrates the importance of strategy pattern in real life.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:10:40Z

Bsampat2: /* Strategy Pattern and Switch statements, a comparison */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern over Switch statements=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm <ref name="Difference"> http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx </ref> at run time. This explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

Strategy pattern is used in real life appliactions <ref name="Application"> [http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf </ref>. This article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code but demonstrates the importance of strategy pattern in real life.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:10:06Z

Bsampat2: /* Application */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm <ref name="Difference"> http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx </ref> at run time. This explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

Strategy pattern is used in real life appliactions <ref name="Application"> [http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf </ref>. This article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code but demonstrates the importance of strategy pattern in real life.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:07:03Z

Bsampat2: /* Strategy Pattern and Switch statements, a comparison */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm <ref name="Difference"> http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx </ref> at run time. This explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:04:53Z

Bsampat2: /* Application */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

=References=

<references />

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:04:18Z

Bsampat2: /* Strategy Pattern, Getting Started */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:03:59Z

Bsampat2: /* Strategy Pattern, Getting Started */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html <references/> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T14:03:18Z

Bsampat2: /* Strategy Pattern, Getting Started */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some difficulties <ref name="Difficulties"> http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html </ref> when design pattern are not used. This reference gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-20T13:57:39Z

Bsampat2: /* Strategy Pattern, Directory of sites */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable way that can be beneficial for a new reader as well as the programmers that want to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some [http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html difficulties] when design pattern are not used. This article gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:57:44Z

Bsampat2: /* Strategy Pattern and Inheritance, a comparison */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable language which can be beneficial for a new reader as well as programmer who wants to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and also explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some [http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html difficulties] when design pattern are not used. This article gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

=Application=

[http://static.usenix.org/publications/library/proceedings/coots97/full_papers/garbinato/garbinato.pdf This] article explains an interesting applications of the Strategy pattern which is to compose reliable Distributed Protocols. This paper does not contain any code or example but demonstrates the importance of strategy pattern in real life.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:55:47Z

Bsampat2: /* Strategy Pattern and Switch statements, a comparison */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable language which can be beneficial for a new reader as well as programmer who wants to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and also explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some [http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html difficulties] when design pattern are not used. This article gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

=Strategy Pattern and Inheritance, a comparison=

[http://docs.doctrine-project.org/en/2.1/cookbook/strategy-cookbook-introduction.html This] is a very good resource that discusses a scenario where Strategy Pattern can be used over Inheritance. It explains the concepts very well and has detailed example in php.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:54:15Z

Bsampat2: /* Strategy Pattern, Getting Started */

=Strategy Pattern, Directory of sites=

Strategy Pattern is a software design pattern that can be used to select a particular algorithm among many available ones at run time depending on certain conditions. A clear definition of the Strategy Pattern can be found [http://en.wikipedia.org/wiki/Strategy_pattern here]. This resource gives a general idea of the pattern, a useful reference for readers that have not used this pattern before. The reference is written in a simple and easily understandable language which can be beneficial for a new reader as well as programmer who wants to have a very high level idea about the pattern. It includes a pictorial representation of the fundamental concept behind the pattern and also explains it using an example in Java. This resource includes a discussion about the Open/Close principle and relates it with the Strategy pattern.

=Strategy Pattern, Getting Started=

Now that you know the basic definitions and concept of the Strategy pattern, [http://www.oodesign.com/strategy-pattern.html this] will give a deeper insight into the pattern. It explains the motivation behind using the Strategy Pattern and various situations where strategy pattern is useful. A Java example is used to provide better understanding of the concept. Further, it adds some details with regard to implementing a Strategy Pattern such as passing data. It includes a discussion about other patterns that are related to the Strategy pattern.

To gain further insight into the working of the Strategy Pattern, [http://www.codeproject.com/Articles/52807/Design-Patterns-Part-1-The-Strategy-Pattern this] resource gives a precise description with well accompanied example. The example is in C# and is very descriptive and easy to understand. The author of the article has shown how to apply the Strategy Pattern to solve a real problem. Additionally, it discusses some of the implementation problems associated with this pattern. This is a good extension to the previous resource.

Patterns make the code better readable and easy to maintain. There are some [http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html difficulties] when design pattern are not used. This article gives a comprehensive idea on the disadvantages of not using a design pattern and how the code becomes readable and easy after using the strategy pattern. This resource demands some work from the reader and helps the reader better understand the pattern.

=Strategy Pattern and Switch statements, a comparison=

This section directs you to an interesting comparison between the Strategy Pattern and Switch statement both of which can be used to dynamically select an algorithm at run time. [http://blogs.microsoft.co.il/blogs/gilf/archive/2009/11/22/applying-strategy-pattern-instead-of-using-switch-statements.aspx This] explains the advantages of using the Strategy Pattern over the Switch statement.

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:49:56Z

Bsampat2: /* Strategy Pattern, Directory of sites */

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:30:57Z

Bsampat2: /* Strategy Pattern, Directory of sites */

CSC/ECE 517 Fall 2012/ch2b 2w64 bg

2012-11-19T20:23:53Z

Bsampat2: Created page with "=Strategy Pattern, Directory of sites="

=Strategy Pattern, Directory of sites=

CSC/ECE 517 Fall 2012

2012-11-19T20:20:53Z

Bsampat2:

*[[CSC/ECE_517_Fall_2012/Table_Of_Contents]]
*[[CSC/ECE 517 Fall 2012/ch1 n xx]]
*[[CSC/ECE 517 Fall 2012/ch1 1w1 rk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w20 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w5 su]]
*[[CSC/ECE 517 Fall 2012/ch1 1w6 pp]]
*[[CSC/ECE 517 Fall 2012/ch1 1w4 aj]]
*[[CSC/ECE 517 Fall 2012/ch1 1w7 am]]
*[[CSC/ECE 517 Fall 2012/ch1 1w8 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w9 av]]
*[[CSC/ECE 517 Fall 2012/ch1 1w10 pk]]
*[[CSC/ECE 517 Fall 2012/ch1 1w11 ap]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w12 mv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w14 gv]]
*[[CSC/ECE 517 Fall 2012/ch1 1w17 ir]]
*[[CSC/ECE 517 Fall 2012/ch1 1w18 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w22 an]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 aa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w21 wi]]
*[[CSC/ECE 517 Fall 2012/ch1 1w31 sa]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w16 br]]
*[[CSC/ECE 517 Fall 2012/ch1a 1w23 as]]
*[[CSC/ECE 517 Fall 2012/ch1 1w24 nr]]
*[[CSC/ECE 517 Fall 2012/ch1 1w15 rt]]
*[[CSC/ECE 517 Fall 2012/ch1 1w3 pl]]
*[[CSC/ECE 517 Fall 2012/ch1 1w32 cm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w37 ss]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w67 ks]]

*[[CSC/ECE 517 Fall 2012/ch1 1w27 ms]]
*[[CSC/ECE 517 Fall 2012/ch1 1w29 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w33 op]]
*[[CSC/ECE 517 Fall 2012/ch1 1w19 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w34 vd]]
*[[CSC/ECE 517 Fall 2012/ch1 1w35 sa]]
*[[CSC/ECE 517 Fall 2012/ch1 1w30 rp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w58 am]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w47 sk]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w69 mv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w44 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w45 is]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w53 kc]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 ar]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w39 sn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w54 go]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w56 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w64 nn]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w66 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w40 as]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w42 js]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w46 sm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w71 gs]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w63 dv]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w55 ms]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w57 mp]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w52 an]]
*[[CSC/ECE_517_Fall_2012/ch1b 1w38 nm]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w60 ac]]
*[[CSC/ECE 517 Fall 2012/ch1b 1w62 rb]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w29 st]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w3_sm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w30 an]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w17 pt]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w31 up]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w9 ms]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w19 is]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w26 aj]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w5 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w16 dp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w8 vp]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w18 as]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w3 jm]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w23 sr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w11_aa]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w15 rr]]
*[[CSC/ECE 517 Fall 2012/ch2a 2w33 pv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w20_aa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w14_bb]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w21_ap]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w13_sm]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w4_sa]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w25_nr]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w12_sv]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w7_ma]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w6_ar]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w32_mk]]
*[[CSC/ECE_517_Fall_2012/ch2a_2w10_rc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w70_sm]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w67_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w40_sn]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w22_sk]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w-1w65_am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w59_bc]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w60_ns]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w47 am]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w69_as]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w39_ka]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w36_av]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w37_ms]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w43_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w53_iv]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w63_sp]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w49_ps]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w52_sj]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w28_dh]]
*[[CSC/ECE 517 Fall 2012/ch1b 2w41 dc]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w59_nm]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w61_ps]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w57]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w42_aa]]
*[[CSC/ECE_517_Fall_2012/ch2b_1w61_ns]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w51_aa]]
*[[CSC/ECE_517_Fall_2012/ch2b_2w45_pg]]
*[[CSC/ECE 517 Fall 2012/ch2b_2w48_aa]]
*[[CSC/ECE 517 Fall 2012/ch2b_1w70_nl]]
*[[CSC/ECE 517 Fall 2012/ch2b 2w64 bg]]

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T15:07:04Z

Bsampat2: /* Multiple method definition */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. [http://blog.rubybestpractices.com/posts/gregory/037-issue-8-uses-for-modules.html Modules] are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. [http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html Interfaces] cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is mixed in where some modules have overloaded methods, the method from the module that was last mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable additional features in object-oriented programming languages. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T15:05:50Z

Bsampat2: /* Conclusion */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. [http://blog.rubybestpractices.com/posts/gregory/037-issue-8-uses-for-modules.html Modules] are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. [http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html Interfaces] cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable additional features in object-oriented programming languages. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T15:00:54Z

Bsampat2: /* Interfaces */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. [http://blog.rubybestpractices.com/posts/gregory/037-issue-8-uses-for-modules.html Modules] are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. [http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html Interfaces] cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable multiple inheritance in programming languages that do not support multiple inheritance. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T15:00:01Z

Bsampat2: /* Interfaces */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. [http://blog.rubybestpractices.com/posts/gregory/037-issue-8-uses-for-modules.html Modules] are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. [http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html Interfaces] cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable multiple inheritance in programming languages that do not support multiple inheritance. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T14:56:14Z

Bsampat2: /* Mixins */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. [http://blog.rubybestpractices.com/posts/gregory/037-issue-8-uses-for-modules.html Modules] are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable multiple inheritance in programming languages that do not support multiple inheritance. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T14:53:49Z

Bsampat2: /* Mixins */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a [http://www.tutorialspoint.com/ruby/ruby_modules.htm module] or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable multiple inheritance in programming languages that do not support multiple inheritance. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-18T14:45:35Z

Bsampat2: /* Conclusion */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces are similar in the fact that they enable multiple inheritance in programming languages that do not support multiple inheritance. They are dissimilar in the way they are implemented but add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T15:12:38Z

Bsampat2: /* See Also */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds 
6. Lucas Carlson; Leonard Richardson (July 2006), [http://shop.oreilly.com/product/9780596523695.do Ruby Cookbook], O'Reilly Media, ISBN 10:0-596-52369-6

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:42:27Z

Bsampat2: /* Multiple method definitions */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definition====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:41:42Z

Bsampat2: /* Inheritance: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:41:28Z

Bsampat2: /* Multiple object behavior: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:41:16Z

Bsampat2: /* Multiple method definitions: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:40:53Z

Bsampat2: /* Overview */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:40:39Z

Bsampat2: /* Overview */

===Overview===

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:38:16Z

Bsampat2: /* Inheritance: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:38:00Z

Bsampat2: /* Inheritance: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:37:45Z

Bsampat2: /* Inheritance: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces whereas Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:36:38Z

Bsampat2: /* Multiple method definitions: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:35:05Z

Bsampat2: /* Multiple method definitions: */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have [http://en.wikipedia.org/wiki/Function_overloading overloaded methods], the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:34:01Z

Bsampat2: /* Mixins */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:33:40Z

Bsampat2: /* Mixins */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:30:23Z

Bsampat2: /* Mixins */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the [http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't repeat yourself] principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:28:29Z

Bsampat2: /* Overview */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an [http://en.wikipedia.org/wiki/Abstract_type abstract] class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:27:16Z

Bsampat2: /* Overview */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in [http://en.wikipedia.org/wiki/Java_(programming_language) Java] programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:26:05Z

Bsampat2: /* Overview */

==Overview==

Mixins are [http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:21:44Z

Bsampat2: /* Conclusion */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. They add more flexibility to object-oriented programming and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:20:17Z

Bsampat2: /* Drawbacks */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding refers to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. However, they have their own disadvantages. Modules add more flexibility to object-oriented programming by the use of DRY principle and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:20:05Z

Bsampat2: /* Drawbacks */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to remember the hierarchy is difficult. Mixins suffer from silent method overriding. Silent method overriding referes to a condition when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. However, they have their own disadvantages. Modules add more flexibility to object-oriented programming by the use of DRY principle and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:17:01Z

Bsampat2: /* Other Comparison */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code and also help us solve the diamond problem, they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to keep in mind the hierarchy is practically impossible. Another issue associated with Mixins pose is silent method overriding. Silent method overriding occurs when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. However, they have their own disadvantages. Modules add more flexibility to object-oriented programming by the use of DRY principle and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:16:28Z

Bsampat2: /* Tabular Comparison */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Other Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain method definitions.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code and also help us solve the diamond problem, they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to keep in mind the hierarchy is practically impossible. Another issue associated with Mixins pose is silent method overriding. Silent method overriding occurs when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. However, they have their own disadvantages. Modules add more flexibility to object-oriented programming by the use of DRY principle and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds

CSC/ECE 517 Fall 2012/ch1a 1w16 br

2012-09-13T00:13:53Z

Bsampat2: /* Achieving Multiple Inheritance */

==Overview==

Mixins are Ruby modules. A module is a grouping of objects under a single name. The objects may be constants, methods, classes, or other modules. Modules are defined in Ruby using the keyword module. They can be incorporated into a class with Ruby’s include statement. This is called a mixin.
Modules are for sharing behavior (methods), while classes are for modeling relationship between objects. Ruby classes can Mixin a module and receive all its methods for free.
An Interface in Java programming language is an abstract type that classes must implement. Interfaces are declared using the interface keyword, and may only contain method signature and constant declarations.
A class that implements an interface must implement all of the methods described in the interface, or be an abstract class.

==Definitions==
===Mixins===
Modules provide a structure to collect classes, methods, and constants into a single, separately defined unit. They provide the simplest and an elegant way to adhere to the Don't repeat yourself<ref>[http://en.wikipedia.org/wiki/Don't_repeat_yourself Don't_repeat_yourself]</ref> principle. This is useful so as to avoid clashes with existing classes, methods, and constants.
Modules are defined in Ruby using the module keyword.
A Mixin is a class that is mixed with a module or a set of modules i.e. the implementation of the modules and the class are intertwined and combined together <ref>[http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_modules.html Mixins] </ref>.
This gives us a neat and controlled way of adding new functionality to classes. Modules are similar to classes in that they hold a collection of methods, variables constants and other modules and class definitions. However, the real usage of a Mixin is exploited when the code in the Mixin starts to interact with code in the class that uses it.
Below is an example for modules and Mixins:
The module ParkingSlot consists of the methods park and unpark

module ParkingSlot
def park
#code to park the car
end
def unpark
#code to unpark the car
end
end
The module ParkingMeter consists of the methods calculate and printreceipt

module ParkingMeter
def calculate
#code to calculate the parking fee
end
def printreceipt
#code to print the receipt
end
end

When a class includes a module via include Module Name, all the methods on that module become instance methods on the class.

class Parking
include ParkingSlot
include ParkingMeter
def printcardetails
#code to print the details and type of car
end
end

The modules ParkingSlot and ParkingMeter are “included” in the Parking class. All the variables and the instance methods of the modules ParkingSlot and ParkingMeter are now said to be “mixed in” into the class. It is now possible for class instances to use these methods defined in the modules as and when required.
p=Parking.new
p.park # -> Method park from module ParkingSlot
p.unpark # -> Method unpark from module ParkingSlot
p.calculate # -> Method calculate from module ParkingMeter
p.printreceipt # -> Method printreceipt from module ParkingMeter
p.printcardetails # -> Calls printCarDetails from class
The class Parking inherits from both the modules and the module methods are now available in Parking. Hence, it is now possible to use the methods with an instance of the Parking class p.
Hence, Mixins can be thought of taking different methods and variables defined in different modules making them available as instance methods in the class as well, thereby extending the class’ functionality. Effectively mixed in modules behave as superclass. 

[[File:ParkingLot.PNG| center]]
 

===Interfaces===
In an object-oriented programming languages such as Java, C#, an interface<ref>[http://download.oracle.com/javase/tutorial/ Interfaces] </ref> is a reference type, similar to a class that can contain only constants, method signatures, and nested types. There are no method bodies. Interfaces cannot be instantiated and they can only be implemented by classes or extended by other interfaces. All methods are public by default and any fields declared in an interface are by default static and final.
Example:
public interface ParkingLot {
boolean add(Car car, int slot);
boolean remove(Car car);
boolean findCar(Int number);
int freeSlotsCount();
int occupiedSlots();
int parkingType();
int calculateParkingFee(int hours, int charge, int duration);
int findParkingSlot();
}
public class Mall implements ParkingLot {
boolean add(Car car, int slot) { //... Code to add a car into the parking lot... }
boolean remove(Car car){ // do something }
boolean findCar(Int number){ // do something }
int freeSlotsCount(){ // do something }
int occupiedSlots(){ // do something }
int parkingType(){ // do something }
int calculateParkingFee(int hours, int charge, int duration){ // do something }
int findParkingSlot(){ // do something }
}
Interfaces play another important role in the object-oriented programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes.

==Mixins vs. Interfaces==
===Similarities and Differences===
Mixins and Interfaces can be considered as a block of code having some variables and methods that can be used by a class. The difference between them is that a Mixin can contain method definitions whereas an Interface cannot.

====Multiple method definitions:====
In a class, when more than one module is Mixed in where some modules have overloaded methods, the method from the module that was last Mixed in into the class will be executed.
module Frog
def sound()
puts "croak..."
end
end

module Dinosaur
def sound()
puts "roar..."
end
end

class Frogosaur
include Frog
include Dinosaur
end

Frogosaur.new.sound 
'''Output:''' 
roar... 
This is because the class Frogosaur can contain only one definition for each method. The users have the flexibility to make use of methods from different modules by rearranging the order of include.
Interfaces, on the other hand, do not offer the flexibility to have different implementation for a same method. This is because the class implementing the interface can provide only one implementation for each method. Hence they offer only one method definition for the user.
public interface Frog {
void sound();
}
public interface Dinasour {
void sound();
}

public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("barks......");
}

public static void main(String args[])
{
new Frogosaur().sound();;
}
}

'''Output:''' 
barks... 

====Multiple object behavior:====
In Ruby, a class’s instance can extend a module and exhibit different behavior than the other instances of the same class.

module Frog
def sound()
puts "croak..."
end
end

module Dinasour
def sound()
puts "roar..."
end
end

class Frogosaur
def sound()
puts "barks..."
end
end

beast1= Frogosaur.new
beast2= Frogosaur.new
beast1.extend(Frog)
beast1.sound
beast2.sound
'''Output:''' 
croak... 
barks... 

Interfaces are implemented by a class and all instances of the class behave in the same way. They can only use the methods of the class to which they belong to.
public class Frogosaur implements Frog,Dinasour{
public void sound()
{
System.out.println("Sounds...");
}
public static void main(String args[])
{
Frogosaur beast1 = new Frogosaur();
Frogosaur beast2 = new Frogosaur();
object1.sound();
object2.sound();
}
}

'''Output:''' 
Sounds... 
Sounds... 

====Enumerable – module and interface====

Ruby’s Arrays have several methods defined in them. To use them, the classes need not be a subclass of Array. The classes can include Enumerable <ref>[http://mattenoble.com/2011/05/30/ruby-enumerables/ Enumerables]</ref> and define the each method to use the array’s methods for free.

class EnumExer
include Enumerable
def initialize(*arrays)
@arrays = arrays
end
def each
@arrays.each { |a| a.each { |x| yield x } }
end
end
ma = EnumExer.new([4, 1], [3], [2])
puts ma.sort

'''Output:''' 
1 
2 
3 
4 

You can observe that although the arguments passed to the ma instance did not have a similar structure, the sort method was able to identify each entry and sort them. This is because the each method was defined to identify and serve all the entries to the sort method.
The methods that are defined for Enumerable modules are:
["all?", "any?", "collect", "detect", "each_with_index", "entries","find", "find_all", "grep", "include?", "inject",
"map", "max","member?", "min", "partition", "reject", "select", "sort", "sort_by","to_a", "zip"]
In Java, to use the methods of Enumerable interface, the class should be a subclass of Array.

public class EnumExer {
static String content_string = "zyxwvutsrqponmlkjihgfedcba";
String a="1", b="2";
public static void main(String args[])
{
char[] content_array = content_string.toCharArray();
java.util.Arrays.sort(content_array);
content_string=new String(content_array);
System.out.println(content_string);
}
}

'''Output:''' 
Abcdefghijklmnopqrstuvwxyz 

In the above example, the string object was converted to a character array to be able to use with the sort method.

====Inheritance:====
Java interfaces can inherit other interfaces but Ruby modules cannot inherit other modules although they can contain classes and methods.
module Wrapper
class Base
# Class Body
end
end

In Java,
public interface Dinasour extends Frog{
//variables and method Declarations
}

==== Achieving Multiple Inheritance ====
Modules and Interfaces help acheive multiple inheritance. 
Interfaces are used in Java to achieve multiple inheritance<ref> [http://csis.pace.edu/~bergin/patterns/multipleinheritance.html Mulitple Inheritance] </ref>. Similarly, modules in Ruby help achieve multiple inheritance. 

In Ruby,

module Frog
def jump()
//Method definition
end
end 
module Dinosaur
def strength()
//Method definition
end
end 
class Frogosaur
include Frog
include Dinosaur
end

In Java,
public interface Frog {
void jump();
} 
public interface Dinasour {
void strength();
} 
public class Frogosaur implements Frog,Dinasour{
//Method Implementations
}

Frogosaur inherits the methods of both frog and dinosaur.

===Tabular Comparison===
{|border="2" cellpadding="5" cellspacing="0" align="center"
|-
! scope="col" | Mixins
! scope="col" | Interfaces

|-
|The number of lines of code is lesser since the 
modules contain the method definition.
|The number of lines of code is bigger since the 
classes have to define the methods.
|-
|More modules in a class makes code less readable.
|The code is more readable since the class contain the 
method definition.
|-
|Modules cannot be inherited and cannot form is-a hierarchy.
|Interfaces can extend another interface and hence can form 
is-a hierarchy.
|}

===Drawbacks===
The drawbacks of the technique of Mixins are very much debated. Though Mixins provide us with an easy way to write flexible and decoupled code and also help us solve the diamond problem, they pose their own problems. In large programs there could be large number of modules and each module could have loads of methods each performing a certain task. To trace the origin of the methods and to keep in mind the hierarchy is practically impossible. Another issue associated with Mixins pose is silent method overriding. Silent method overriding occurs when different modules are included in a class and each module have a method with the same definition. In such a case, the method which gets executed depends upon the way it is included in the class and this is done without any sort of message to the user (silently). In large scale applications this could certainly be an issue considering the number of modules that would be mixed in and it would be difficult to keep track of the hierarchy in which the modules were included.
Although Java provides polymorphic behavior with the use of interfaces, they sometimes tend to be very slow. The implementation of interfaces is also limited to public methods and constants with no implementation.

==Conclusion==
Modules and Interfaces offer many advantages. However, they have their own disadvantages. Modules add more flexibility to object-oriented programming by the use of DRY principle and are easy to maintain.

==References==
<references/>

==See Also==
1. http://ruby.about.com/od/beginningruby/a/mixin.htm/ 
2. http://juixe.com/techknow/index.php/2006/06/15/mixins-in-ruby/ 
3. http://www.innovationontherun.com/why-rubys-mixins-gives-rails-an-advantage-over-java-frameworks/ 
4. http://pg-server.csc.ncsu.edu/mediawiki/index.php?title=CSC/ECE_517_Fall_2010/ch3_3b_sv&printable=yes 
5. http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/ch2_2c_ds